48 major outages in twelve months. What is going on at GitHub?

Crowds of fun-seekers exploring a city on foot, "

Arjan Franzen

29 August 2026

Illustration: a bridge resting on two piers, the right one cracked and held up by scaffolding, while traffic keeps flowing across it.

On 17 August, GitHub was down for the best part of eight hours. One afternoon, and roughly the entire annual budget of permitted downtime was gone. I spent that afternoon staring at a pipeline that was going nowhere, thinking: this isn't the first time this year.

A word up front, because this is a soapbox and not a product comparison. We use both GitHub and GitLab, every day, for clients and for ourselves. I don't have a camp. What I did have was an uneasy feeling, and when I went looking for the numbers it turned out not to be a feeling.

The numbers

Between May 2025 and April 2026, GitHub logged 257 incidents, 48 of them major outages. February 2026 was the worst month with 37. The three nines — 99.9 percent — that Enterprise customers are contractually promised were not met over that period.

But the most interesting figure is a different one: 83 of those 257 incidents were caused by load and capacity. By far the largest single cause. So this isn't a platform tripping over a bad migration or a broken deploy. This is a platform taking in more work than it can carry.

Bar chart: of GitHub's 257 incidents between May 2025 and April 2026, 83 were caused by load and capacity; below it GitLab with 99.98 percent availability in November 2025.

GitHub's incidents between May 2025 and April 2026: 83 of the 257 were caused by load and capacity, by far the largest single cause. GitLab reports a different measure — monthly availability — and came in at 99.98 and 100 percent.

In fairness: more reported incidents can also mean more transparency. A vendor that publishes everything looks worse than one that stays quiet. But these reports come from GitHub itself, and they don't make happy reading.

Why this year in particular

That capacity figure is no coincidence; it's a symptom of the year we're in. A team of ten used to push maybe thirty times a day. That same team with agents alongside them opens pull requests, runs pipelines, does reviews and restarts builds at a rate no capacity plan from five years ago was ever built for.

The result is bitter. Exactly when your platform needs to take the most, it becomes the bottleneck. Your agents sit waiting for a runner. The most expensive part of your toolchain is no longer the model — it's the queue in front of it. We worked out what that waiting costs an engineer per day.

And then it became a division

In August 2025, Thomas Dohmke stepped down as GitHub's CEO. No successor was appointed. Leadership has since reported directly into Microsoft's CoreAI team under Jay Parikh. After nearly seven years as an independently operating unit, GitHub is now literally a division.

That isn't a gut feeling or a vibe. That's the org chart.

The reverse Midas touch

For years I've been saying Microsoft suffers from a reverse Midas touch: everything they lay a hand on that has anything to do with the internet turns to crap. It's a joke, but the list underneath it isn't.

Skype: 8.5 billion dollars in 2011, switched off on 5 May 2025 after 22 years. aQuantive: 6.3 billion in 2007 to take on Google in advertising, written off almost entirely by 2012. Nokia: 7.2 billion paid, 7.6 billion written off — the largest write-off Microsoft has ever taken, plus 18,000 redundancies.

And then Yahoo, my personal favourite, because Yahoo got away. Microsoft bid 44.6 billion dollars in February 2008. Yahoo's board judged that the offer substantially undervalued the company and rejected it unanimously; Microsoft withdrew in May. Eight years later the core business went for around 4.5 billion. Apparently you don't even have to be touched.

But here I have to correct myself, and I'm happy to: with GitHub, for seven years, it didn't happen. Seven years in which GitHub simply stayed GitHub, with its own CEO, its own culture and a product direction that didn't come out of Redmond. That's the longest remission on the entire list. It proves it can be done. Which is exactly why last year's news is so irritating.

Bitbucket is the warning, not the punchline

Anyone who thinks this is only about Microsoft should look at Bitbucket. Atlassian bought it in 2010 and I was genuinely enthusiastic at the time. Moving from Bamboo to Bitbucket was a relief, and Bitbucket Pipelines was among the first to run CI entirely on Docker images: your whole build environment became one line in a yaml file. In those years, that was genuinely ahead.

The turning point came in August 2019, with the announcement that Mercurial was going. By 1 June 2020 those repositories were gone. Bitbucket was the Mercurial host — that's where it came from, that was its distinction. That isn't a product decision, that's clearing out your own reason for existing because it no longer fits the quarterly plan.

What came after is a slow decay that anyone who still logs in will recognise. I won't dwell on it here, or this becomes a different article. Short version: for Bitbucket, we fear help arrives too late.

Meanwhile, GitLab keeps stacking

And then there's GitLab, doing the same boring trick it has done for years: delivering. Source control, CI/CD, security scanning, registry and planning sit in one product rather than in a marketplace full of integrations you wire together yourself. On availability, GitLab reported 99.98 percent in November 2025 and 100 percent in August and September. Both vendors promise 99.9. One of them is hitting it. Which of the two fits a given organisation is a question in its own right, and exactly what our tech consultancy exists for.

Before anyone concludes I've become a GitLab fanboy: GitLab is a listed company that was reported to be of acquisition interest to Datadog in July 2024 and again in October 2025. Unconfirmed, and analysts were sceptical, so treat it as noise. But GitLab's independence is a market question, not a law of nature. Anyone walking away from GitHub today because it became a division could be living through the same thing in two years.

Where we stand

We don't judge and we don't choose. At ZEN, clients run on GitLab and on GitHub, and that isn't changing; we build the delivery pipeline around it, not the vendor choice. What we do think: one large supplier of source control and CI is not a market. It's a single point of failure with a sales department.

There need to be at least two. Not because competition is a virtue in itself, but because the day one of them falls over — for eight hours, or for good — must not be a day when half the industry stops. And such a day is no abstraction: it lands straight in your DORA numbers. Commercially, we gain nothing from GitHub winning, and just as little from GitLab winning.

So: GitHub, fix it. Capacity is a solvable problem and you have the richest parent in the world. We need you. GitLab, keep doing what you're doing. And Bitbucket — I'm genuinely sorry, because you were once the most fun of the three.

no image placeholder

Streamline Your Software Delivery