Deep Dive

The Platform That Forgot It Was Infrastructure

Saturday 2 May 2026 By Mat + Orac topic: GitHub's reliability collapse, the developer exodus it's triggering, and what it reveals about Microsoft's priorities

The Journal of X Marks

Mitchell Hashimoto is GitHub user number 1,299. He joined in February 2008, back when the platform was still a scrappy Git hosting startup, and spent eighteen years building his professional identity there — Vagrant, Terraform, Consul, and now Ghostty, a terminal emulator that’s become one of the most-watched projects in the ecosystem. He describes GitHub as the place that’s made him “most happy” over nearly two decades, the thing he made time for even on his honeymoon.

So when Hashimoto published a post titled “Ghostty Is Leaving GitHub” on April 29, the relevant question wasn’t whether he was being dramatic. It was what it takes to make someone with that much emotional equity walk away. The answer is a journal he’d been keeping for a month, marking every day a GitHub outage blocked his work. Almost every day had an X.

“I’ve been angry about it. I’ve hurt people’s feelings. I’ve been lashing out,” he wrote. “Because GitHub is failing me, every single day, and it is personal. It is irrationally personal.”

This isn’t a disgruntled user venting on a forum. This is the founder of HashiCorp — someone who built his entire open-source career on GitHub — declaring the platform is “no longer a place for serious work.” And he’s not alone. Five months earlier, in November 2025, the Zig programming language moved its canonical repository to Codeberg, making GitHub read-only. Andrew Kelley, Zig’s creator, cited “inexcusable bugs” in GitHub Actions and a CI system so broken that even master branch commits weren’t getting checked. Two significant open-source projects, led by two deeply credible engineers, arriving at the same conclusion independently. That’s not a trend piece. That’s a signal.

The Autopsy of an Uptime Number

GitHub’s official availability reports for Q1 2026 read like a case study in cascading technical debt. But the pattern they reveal is more damning than any individual incident.

March 3: A deployment intended to reduce load on the user settings caching mechanism contained a bug that expired every user’s cache simultaneously, causing a massive write storm. Result: ~40% request failures on github.com, ~43% on the API, ~21% on Copilot. Duration: 70 minutes. The kicker? This was the same underlying caching mechanism that caused an earlier outage in February. Same bug, same component, two months apart.

March 5: A resiliency update to the Redis load balancer introduced incorrect configuration, misrouting internal traffic. GitHub Actions — the CI/CD backbone that every automated workflow depends on — saw 95% of workflow runs fail to start within five minutes, with an average delay of thirty minutes. Ten percent failed outright. Duration: nearly three hours. A routine infrastructure update, deployed without adequate validation, crippled the platform’s most critical developer tool.

March 19–20: The Copilot Coding Agent went down two nights in a row. A system authentication issue prevented the service from connecting to its datastore. The first incident peaked at 93% errors. The second, which occurred because the first wasn’t fully remediated, peaked at 100% with significant retry amplification — the system hammering itself harder as it failed.

March 24: Microsoft Teams integration broke, with a peak error rate of 90%, caused by an upstream dependency outage that GitHub’s systems couldn’t gracefully absorb.

What connects these isn’t the variety of services affected — it’s the nature of the triggers. A cache update. A Redis config change. A credential rotation. Routine operational work that any mature platform should absorb without incident. Instead, each one cascaded into broad outages because the codebase and operations culture have lost the slack to absorb normal change safely. The system is so tightly coupled, so under-resourced for its load, that the smallest perturbation sends shockwaves through dependent services.

Then there’s the matter of what GitHub’s status page doesn’t count. Independent tracking via StatusGator has documented incidents GitHub never officially acknowledged: a 15.5-hour Copilot outage on April 14, a 3-hour Copilot failure on March 31, rate-limiting errors on March 27. GitHub’s status page excludes “Degraded Performance” from its downtime calculations, meaning headline uptime percentages stay respectable while developer workflows are actively blocked. The numbers GitHub publishes and the pain developers feel are measuring different things. As one Hacker News commenter put it: “GitHub has suffered dozens and dozens of outages since the beginning of the year. It is notably less available and reliable than it was even as recently as last year. People have created dashboards and heatmaps showing how bad GitHub has become.”

10x Wasn’t Enough. 30x Might Not Be Either.

GitHub began executing a 10x capacity plan in October 2025. By February 2026, it was clear they needed to design for 30x scale. The trigger was the mainstream adoption of AI coding agents — agentic workflows where AI systems don’t just suggest completions but actively open pull requests, run CI, push code, and iterate on failures. These workflows don’t interact with GitHub the way humans do. They’re faster, more repetitive, and dramatically more API-intensive.

The growth is across every dimension: repository creation, pull request activity, API calls, automation, large monorepo workloads. And it doesn’t stress systems in isolation. As GitHub’s own engineering blog acknowledges, “a single pull request can now impact a complex web of services, from Git storage to CI/CD pipelines and databases. Small inefficiencies, when amplified at scale, lead to cascading failures.”

The April incidents illustrate this perfectly. On April 23, a regression in merge queue operations corrupted 2,092 pull requests across 658 repositories — incorrect merge commits in squash scenarios, with some default branches that couldn’t be automatically repaired. This wasn’t an outage. It was a correctness failure: the platform silently produced wrong results for three and a half hours, and the only detection mechanism was customer support inquiries. Four days later, an Elasticsearch overload — likely triggered by a botnet attack — caused pull request lists to simply vanish from the UI.

The critical insight here, and it’s one that GitHub’s public communications have been careful to sidestep, is that the 30x capacity plan addresses load. It doesn’t address culture. The April 23 merge queue bug points to internal engineering debt that no amount of scaling fixes: feature flag gating that allows unreleased code paths to reach production, test coverage that exercises single-PR cases but not multi-PR squash scenarios, and monitoring that doesn’t validate merge correctness. Capacity work makes the platform bigger. It doesn’t make it better.

GitHub has since reordered its priorities to “Availability First, Capacity Second, New Features Third” — a sequence that implicitly admits the previous ordering was wrong. They’re isolating critical services, moving compute to Azure, and exploring multi-cloud architecture. These are sensible steps. But they’re also the kind of infrastructure work that takes quarters to years to bear fruit, and the trust damage is accumulating weekly.

The Microsoft Problem

Microsoft acquired GitHub for $7.5 billion in 2018. The stated rationale was developer mindshare, not revenue — GitHub’s ARR at the time was modest, perhaps $200–300 million, and the platform has always been structurally subsidised by the ecosystem value it provides to Microsoft’s broader portfolio: Azure, VS Code, npm, Copilot.

This “strategic asset” framing creates exactly the incentives you’d expect. Operational reliability — the unglamorous work of keeping caches from exploding and Redis configs from cascading — is boring, expensive, and low-prestige inside a company that sells enterprise software. Revenue-generating features like Copilot and Enterprise tiers are exciting, visible, and career-advancing. The result is a predictable pattern of underinvestment in the plumbing and overinvestment in the fixtures.

The irony is acute: Copilot, Microsoft’s highest-priority monetisation play, is now generating the load that’s breaking the platform. The 30x capacity problem is in significant part a Copilot problem. AI agents creating repos, opening PRs, running Actions, and hammering APIs — these are the workflows that turned a platform designed for human-speed collaboration into something that needs to handle machine-speed traffic. The thing Microsoft was most eager to build is the thing that’s cracking the foundation it’s built on.

As one Hacker News commenter observed: “I’m not sure how we ever could have expected GitHub to continue with or add quality when being built by the same company that also builds MS Teams. There are clearly the wrong quality levers at work inside Microsoft.” The comparison is apt. Teams has been Microsoft’s other high-profile platform reliability embarrassment, and the pattern — aggressive feature shipping atop insufficiently maintained infrastructure — rhymes uncomfortably.

GitHub has since announced a shift to Copilot usage-based billing starting June 2026, which creates a more direct financial incentive to fix the infrastructure. Whether that’s enough, and whether it comes in time to retain the community, is the open question. Copilot was, until now, effectively loss-leading — $10/month for a service that, as Mat notes, was “infeasibly cheap” while simultaneously being “too slow to actually be useful.” That’s not a product strategy. That’s a developer capture play wearing a product strategy’s clothes.

The Prestige Drain

The real barrier to leaving GitHub isn’t technical — Git is distributed by design, and the alternatives are functional. The barrier is network effect. GitHub is where developers go to find things. Stars are a reputation layer. Issues are a discourse channel. Pull requests are how open-source governance happens. Moving a repository is trivial. Moving a community is not.

But this network effect is asymmetric. It’s strongest for public open-source projects that depend on discoverability, and weakest for enterprise or private repos that have viable alternatives in GitLab, Azure DevOps, or self-hosted Forgejo. What’s left in GitHub’s “captive” bucket is mid-tier public projects — large enough to benefit from the platform’s SEO and social proof, but not so large or sophisticated that they push the platform hard enough to feel the pain.

The erosion risk isn’t a sudden collapse. It’s a slow prestige drain. When Hashimoto writes “After 18 years, I’ve got to go” — and 3,481 Hacker News users upvote it — the damage isn’t to GitHub’s server load. It’s to the platform’s status as the place where serious projects live. If enough high-signal projects leave and write about it, the social proof that sustains the network effect begins to decay. That takes years, but it’s very hard to reverse.

The alternatives landscape has its own texture. Codeberg and Forgejo represent the principled, OSS-first choice — where Zig went — but their CI ecosystem is thin. GitLab is the enterprise-hardened option with genuinely competitive features and strong CI, but less discovery and network effect. Sourcehut is spartan and email-based, for developers who consider that a feature. None of them are drop-in replacements for the full GitHub experience, but they don’t need to be. They only need to be good enough for the specific workflows that GitHub is now failing.

Hashimoto’s conditions for return are telling: “real results and improvements, not words and promises.” GitHub’s CTO Vlad Fedorov has issued a formal apology and outlined technical remediations. But apologies are cheap in platform economics. What matters is whether, six months from now, the journal of X marks has more empty pages than full ones.

The Verdict

GitHub’s reliability crisis isn’t a mystery. It’s the predictable outcome of a decade of deferred maintenance under an owner whose primary interest is enterprise software sales, not developer infrastructure operations. The AI agent explosion of late 2025 didn’t create the problems — it just made pretending otherwise impossible.

Microsoft absolutely can fix this. They built Azure, which handles vastly more complex workloads at far greater scale. But fixing it requires treating GitHub as a product again — something deserving operational investment proportional to its importance — rather than a funnel for developer mindshare and Copilot subscriptions.

The data suggests the inflection point has already passed. When GitHub’s uptime drops below 85% in a month, when its own status page incidents go unacknowledged for hours or days, when merge queue bugs silently corrupt two thousand pull requests and the only detection mechanism is angry users filing support tickets — these aren’t growing pains. They’re the symptoms of a platform that has been running on fumes.

Steve Ballmer’s infamous “Developers! Developers! Developers!” was, whatever its meme value, a genuine expression of building attractive solutions and trusting that developers would come. The culture has shifted. Developers will put up with a remarkable amount of degradation — enterprise IT has trained them for it — but there’s a threshold. Hashimoto and Kelley have found theirs. The question is how many others are keeping their own journal of X marks, and how close they are to writing their own version of “After N years, I’ve got to go.”

Sources