The most damning single artifact in this whole story is the disappearance of aggregate uptime numbers from GitHub’s own status page. If you had checked the platform’s status page a year ago you could see rolling uptime figures. Now you cannot. An independent developer, Marek Šuppa, built a mirror called The Missing GitHub Status Page that rebuilds those numbers from archived incident data. It is not flattering.

IncidentHub, an independent status aggregator, filled the reporting vacuum with a full audit from May 2025 through April 2026. Their headline numbers: 257 total incidents, 48 major outages, and a clear upward trend since December 2025. GitHub Actions is the most bruised component with 57 individual outages. Copilot is right behind with 44 outages and nine of them major, ten of which came in February 2026 alone. When The Register looked at the same data in February, its conclusion was blunt: GitHub was struggling to hit three-nines availability, which for a platform Microsoft bought for $7.5 billion in 2018 is embarrassing.

What makes the situation harder to spin is that the pattern is not random. February 2026 alone recorded 37 incidents, the worst single month in the tracked period. Both February and April 2026 tied for the worst months by major incident count with seven each. That is not a series of unrelated bad breaks. It is a consistent slope, month after month, in the direction of more failures, longer failures, and failures that cascade across more services. Any engineering leader looking at that pattern reaches the same conclusion GitHub’s own CTO reached in his April memo: this is a scaling problem, and it is going to take a lot more capacity to solve.

Hashimoto is not a random developer. He co-founded HashiCorp, the infrastructure company that IBM acquired in 2025 for roughly $6.4 billion, and he is one of the more recognizable technical voices in modern DevOps. When someone at his level publicly says a platform “is no longer a place for serious work” and moves a project with 52,000 stars off it, the industry pays attention. His stated trigger was a specific two-hour and thirteen-minute Copilot Cloud Agent outage on April 27, 2026, but his real complaint was cumulative: every single day for months he had lost hours to some GitHub subsystem failure.

The most damaging line in his post was not the exit announcement. It was the phrase, “I want to ship software, and it doesn’t want me to ship software.” That is a specific accusation. It says the platform’s product priorities are actively getting in the way of the workflow it exists to serve. GitHub COO Kyle Daigle apologized directly on X. But an apology from the COO does not fix the underlying architecture, and everyone in the industry knows it. Hashimoto’s exit reframed the story. Before that post, GitHub outages were a technical inconvenience. After it, they became a strategic risk that competitors could exploit.

Here is the part that is impossible to overstate. In his April 2026 blog post, CTO Vlad Fedorov named the driver of the load surge in plain terms: “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.” Agentic workflows means AI coding agents, and the flagship agentic product in the ecosystem is Copilot, and Copilot is owned by GitHub, and GitHub is owned by Microsoft.

Repository creation, pull request activity, API usage, automation, and large-repository workloads are all growing quickly, per Fedorov’s own numbers. That is happening because Copilot Cloud Agent and similar agentic tools are creating pull requests and running Actions workflows around the clock at a rate no human team could match. GitHub’s platform was designed for humans clicking merge buttons. It is now being asked to serve autonomous agents making thousands of concurrent operations. Microsoft acquired GitHub in October 2018 for $7.5 billion. Copilot launched in June 2021. The commercial pressure to grow Copilot revenue, particularly after Microsoft folded GitHub into its CoreAI organization in August 2025, competes directly with the engineering attention reliability now demands. That is the whole loop.

The recent June 2026 incident record makes the pattern painfully concrete. Between June 16 and June 28, GitHub logged Copilot degradation on at least five separate days, including a 2.5-day Copilot Cloud Agent incident where up to 26% of agent tool calls failed silently. Silent failures are the worst kind, because agent jobs appear to succeed while actually doing nothing. That is exactly the failure mode that erodes trust fastest, because developers stop believing the CI signal even after the platform is back up.

The most quietly alarming line in Fedorov’s April 2026 post was the scale revision. GitHub started a 10X capacity plan in October 2025. Four months later, in February 2026, they realized they needed to design for a future that requires 30X today’s scale. That is not a normal quarterly correction. That is engineering leadership admitting the load projection they built their reliability plan around was off by a factor of three, in the direction of more load, in less than half a year.

Fedorov identified the technical causes with unusual candor: “rapid load growth, architectural coupling that allowed localized issues to cascade across critical services, and inability of the system to adequately shed load from misbehaving clients.” That is a distributed systems engineer’s way of saying that when one thing on GitHub breaks it now takes other things with it, and there is no reliable way to isolate the damage in real time. Root cause analyses on the February 2 and March 5, 2026 outages revealed single points of failure, which is a term any senior infrastructure engineer will tell you should not appear in the post-mortem of a platform hosting the world’s code.

When GitHub CEO Thomas Dohmke stepped down in August 2025, Microsoft made a decision that a lot of ex-GitHub employees found revealing. They did not replace him. Instead, GitHub was folded directly into Microsoft’s CoreAI organization, with the remaining leadership reporting up through Microsoft executives. For a company that had spent seven years since its 2018 acquisition operating with significant independence, this was a real structural change. Freelance developer David Bushell put it starkly in his post: Microsoft has turned GitHub into an expensive liability.

The practical result is that there is no longer anyone at the very top of GitHub whose sole job is to be GitHub’s advocate against competing internal priorities. Every trade-off between reliability investment and Copilot growth now runs through Microsoft’s AI-first executive structure, and the AI-first structure has clear incentives to keep pushing agentic products at maximum velocity. This is not a conspiracy. It is just organizational math. If your reporting line goes to Microsoft’s CoreAI leadership, the CoreAI product roadmap will get more attention than the GitHub Actions capacity plan. And that is exactly what the outage data seems to be showing.

Fedorov’s April post did explicitly commit to reliability improvements, and Microsoft has both the capital and the engineering depth to deliver them. What is missing is a public commitment on when the developer community should expect visible improvement. Nine months into the crisis, that number still has not appeared in any Microsoft communication. Until it does, the working assumption inside most engineering leadership teams is that GitHub reliability is not going to snap back on any specific timeline they can plan around.