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: this is a soapbox, 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, according to an analysis of its own status page, GitHub logged 257 incidents, 48 of them major outages, with February 2026 as the worst month. 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 platform isn't tripping over a bad migration or a broken deploy; it is taking in more work than it can carry. More reported incidents can also mean more openness, I'll grant that, but these reports come from GitHub itself.

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.

Why this year in particular

That capacity figure is 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.

A division, and the reverse Midas touch

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, the org chart has GitHub down as a division. 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. Nokia: 7.2 billion paid, 7.6 billion written off, plus 18,000 redundancies. Yahoo is my personal favourite, because Yahoo got away: the board unanimously rejected Microsoft's 44.6 billion dollar bid of February 2008 and sold the core business eight years later for 4.5 billion.

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 and a product direction that didn't come out of Redmond. That's the longest remission on the entire list, 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: Bitbucket Pipelines was among the first to run CI entirely on Docker images, your whole build environment became one line in a yaml file.

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. With that, Bitbucket cleared out its own reason for existing, because it no longer fitted the quarterly plan. What came after is a slow decay that anyone who still logs in will recognise, and for Bitbucket we fear help arrives too late.

Where we stand

Meanwhile GitLab has been doing the same boring trick for years: delivering. Source control, CI/CD, scanning, registry and planning in one product, rather than 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. Before anyone concludes I've become a GitLab fanboy: acquisition interest from Datadog has been reported twice, most recently in October 2025, unconfirmed and treated sceptically by analysts, so take 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. Which of the two fits you is exactly what our tech consultancy exists for.

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. 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, because the day one of them falls over, for eight hours or for good, must not be a day when half the industry stops. Such a day lands straight in your DORA numbers, by the way. 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

More information

Cloud & platform

Landing zones on AWS and Google Cloud, CI/CD and observability. We set it up, and we keep it running.

See cloud & platform →