What’s gone wrong at GitHub?

Estimated reading time: 8 minutes

Key takeaways:

• GitHub’s uptime has plummeted.
• Rapidly scaling agentic AI workflows have overwhelmed the platform.
• Focused on recovery, GitHub’s leadership has shifted from growth at all costs to an availability first mandate, but patience is running out.

---

For most of its life, GitHub has been remarkably reliable.  Then, somewhere in the last year or so, that stopped being the case. What happened?

In 2024, GitHub logged 119 service incidents, including 26 major ones. The average resolution time was around 106 minutes. Frustrating, but manageable. 

Then, between May 2025 and April 2026, incident monitoring service IncidentHub tracked 257 separate incidents on GitHub, of which 48 were classified as major outages. That’s roughly one significant disruption per week, with February’s 37 incidents making it the worst month on record. GitHub’s CI/CD system Actions was the most battered service, suffering 57 outages in the same 12-month period. An Actions outage can freeze an entire engineering workflow.

The industry standard for a production service is 99.9%. GitHub’s official status page has an uptime of 99.79%, but an unofficial status tracker built byMarek Šuppa suggests that GitHub’s measured uptime over the last 90 days sits at just 84.88%.  

“What this unofficial status tracker aims to do is to extract the data from GitHub’s own status reports for all services and aggregate them both per-service as well as together,” Šuppa told me. “The difference is that we do not really know what goes into the GitHub numbers you averaged out – hence why I put that small site together to recompute them from the source reports themselves.”

An exodus

These reliability woes have triggered a visible exodus of high-profile users.

In December 2025, the Zig programming language project migrated to Codeberg, a nonprofit alternative, citing not just bugs but what its maintainers called a “rotted” engineering culture. They pointed to a critical bug in GitHub Actions that had hung build servers indefinitely. Having been reported in April 2025, it was fixed months later. 

Last month, Mitchell Hashimoto, an early adopter of GitHub and co-founder of HashiCorp, the company behind Vagrant and Terraform, wrote that he had spent the past month keeping a journal, marking an X next to every day where a GitHub outage had negatively affected his ability to work. Almost every day had an X. On the day he was writing the post, he had been unable to do any pull request review for two hours because of a GitHub Actions outage.

“This is no longer a place for serious work, if it blocks you out for hours per day, every day,” he wrote. He announced that his Ghostty terminal emulator project, which has over 52,000 GitHub stars, would be leaving the platform.“I want to ship software, and it doesn’t want me to ship software. I want it to be better,” he wrote.

The reaction from GitHub was swift. The company’s chief operating officer responded to Hashimoto on X, saying “I’m sorry. The team is going to keep working to make GitHub something you can come back to with real proof, not words.” 

Is AI precipitating GitHub’s reliability crisis?

In a blog post responding to two serious incidents in late April 2026, GitHub’s CTO Vlad Fedorov described the core problem plainly: the platform wasn’t built for the scale it’s now being asked to handle. “We started executing our plan to increase GitHub’s capacity by 10X in October 2025, with a goal of substantially improving reliability and failover,” Fedorov writes. “By February 2026, it was clear that we needed to design for a future that requires 30X today’s scale.”

The proximate cause is the explosion of code resulting from AI-assisted development. “The main driver is a rapid change in how software is being built. Since the second half of December 2025, agentic development workflows have accelerated sharply. By nearly every measure, the direction is already clear: repository creation, pull request activity, API usage, automation, and large-repository workloads are all growing quickly.”

If we take Fedorov’s argument that the problem is one of rapid scaling caused by AI, it’s hard to ignore the irony. GitHub Copilot launched as a technical preview in June 2021 and became the first AI-powered coding tool to achieve mainstream adoption among professional developers. The firm actively evangelized AI code generation, helped create the market for it, and trained an entire generation of developers to lean on it. It is now buckling under the weight of the automated, AI-generated activity that followed. 

That tension is compounded by the fact that Microsoft, which acquired GitHub for $7.5 billion in 2018, has made Copilot one of its most strategically important products, integrating it across its entire software suite. It is difficult to imagine that the commercial pressure to keep growing Copilot revenue hasn’t competed for the engineering attention that reliability now urgently demands. 

That pressure has already reshaped GitHub’s leadership structure. When CEO Thomas Dohmke stepped down in August 2025, Microsoft chose not to replace him, instead folding GitHub directly into its CoreAI organization, with the remaining leadership reporting to Microsoft executives. The company that once prided itself on operating independently since its acquisition no longer has anyone at the top whose job is solely to be GitHub’s advocate.

Freelance developer David Bushell, writing in his post GitHub is Sinking, puts it bluntly: Microsoft has turned GitHub into an expensive liability. His argument is that the platform is being flooded with low-quality, AI-generated code, issues, and pull requests – the kind of automated noise that clogs up repositories and drowns out legitimate work – to the point where they are  “effectively DDoSing themselves with slop.”   

In other words, GitHub is being brought to its knees not by outside attackers, but by the weight of its own AI-driven activity. Bushell’s conclusion is pointed: “Network effects are hard to topple but if anyone can do it, Microsoft can.” 

The problems aren’t just scale though. The April 23rd incident was caused by a regression in GitHub’s merge queue feature, which meant that for merge groups containing more than one pull request using the squash merge strategy, changes from previously merged pull requests were silently reverted. Some 2,092 pull requests across 658 repositories were affected. The commits were still there, but the default branches of affected repositories were left in incorrect states that GitHub couldn’t repair safely and automatically.

The root cause was an incomplete feature flag. A new code path was supposed to be gated behind a flag for an unreleased feature, but the gating was incomplete. The new behavior activated in production, and the existing monitoring didn’t catch it because the issue was about merge correctness rather than availability; the service appeared to be up, so no alarms fired. The bug was eventually identified through customer reports.

This feels like poor architectural practice, rather than a scaling problem driven by AI.

Four days later, a separate incident took down GitHub’s Elasticsearch subsystem, which powers search across issues, pull requests, and projects. The cluster buckled under load apparently triggered by a botnet attack, leaving significant parts of the user interface showing empty results and causing widespread disruption.

What a better GitHub would look like

Not everyone is taking a combative stance. Hannah Foxwell, writing in the AI for the rest of us she and I co-write, pondered what the crisis says about GitHub’s role in the world. 

“We need GitHub. It is critical global infrastructure, and it is struggling under the weight of millions (if not billions) of AI agents spewing out code.” Foxwell ended with a justifiable note of sympathy for the engineers caught in the middle of an almost impossibly fast-moving situation: the people trying to fix this are working under enormous pressure.

Andrew Nesbitt, who worked at GitHub and has spent a decade thinking about open source infrastructure, published a blog, a GitHub for maintainers, arguing that while most wishlist items for a GitHub replacement focus on individual developer workflows, those problems are already being solved elsewhere. 

Stacked PRs are handled by tools like Graphite and Jujutsu; code review is moving into editors like Cursor and VS Code. What nobody is talking about, Nesbitt argues, is the thing only a platform with GitHub’s vantage point could provide: visibility into the relationships between projects. Who depends on whom, what happens to a library when its maintainer goes quiet, whether a change you’re about to ship will break thousands of downstream projects. That’s the layer GitHub has barely touched in years , and the one none of the would-be replacements are addressing either.

The bigger picture

GitHub serves over 100 million developers and is seeing genuinely unprecedented growth. It has been unusually transparent in its post-incident write-ups, publishing detailed root cause analyses and committing to specific architectural changes.

But transparency after the fact isn’t the same as reliability, and the community’s patience is visibly fraying.

It’s worth asking why GitHub seems to be struggling in a way that comparable infrastructure isn’t. PyPI, npm, and GitLab are all handling growth from the same AI-driven development boom without comparable public meltdowns. The difference is likely GitHub’s unique position at the centre of the agentic workflow. As well as hosting code, GitHub is the place where AI agents open pull requests, trigger CI runs, consume APIs, and interact with repositories at machine speed. 

GitHub’s stated priorities are now availability first, capacity second, new features third. That’s the right order, but whether the organization can hold to it, with all the competitive and commercial pressure to keep shipping Copilot features, remains to be seen.

For the moment, the platform that became synonymous with open source and made distributed collaboration feel effortless, is facing an uncomfortable reckoning: the gap between what it has always promised and what it is currently able to deliver.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.