Two numbers explain most of what went wrong at GitHub last week. Monthly commits on the platform stood at 1.4 billion in April. By August they had reached 2.9 billion. Somewhere between those figures, a component in the company's Central US facility hit a ceiling it could not grow past, and on August 17 the largest code host on the internet spent 7 hours and 47 minutes inside a critical incident.
The company's account, attributed to chief technology officer Vladimir Fedorov, rules out the explanations engineers usually reach for first. No deploy triggered it. No configuration change triggered it. Both this failure and an Actions breakdown eleven days earlier were, in GitHub's framing, capacity problems — components that should have been scaled up before demand arrived, and were not.
The Blast Radius
Authentication was the pivot point. Once capacity pressure reached it, the damage spread across github.com, Actions, the REST and GraphQL APIs, pull requests, issues, and Copilot simultaneously. External monitoring during the window put error rates near 20% for web and API traffic and roughly 50% for archive and raw repository downloads, with the disruption beginning around 13:40 UTC.
Getting back was not a single action. Engineers rerouted traffic, walled off the failing infrastructure, and restored services in stages. Most came back the same day. Copilot did not, and the reason is instructive: failures there set off a client-side retry loop that generated additional load precisely when the platform had the least capacity to absorb it. That amplification had to be contained before traffic could safely return.
Independent analyses of the incident have pointed to a cascade involving autoscaling that watched the wrong service and downstream proxy nodes exhausting their limits, with client retry behavior multiplying token-service requests by an order of magnitude. GitHub's own writeup does not go into that level of mechanism, reserving it for a separate root cause analysis with a full technical timeline.
Hardware Against a Power Ceiling
GitHub is not short on spending. The company says it has brought online more than 3 million CPU cores, 120 petabytes of high-speed storage, and substantial additional network capacity as part of reliability commitments made earlier this year.
The constraint turned out to be electrical rather than financial. GitHub installed as much hardware as the available power in its existing data centers permitted — and then leaned harder on Azure. That migration has moved fast: Azure handled 12% of platform load in May and now carries roughly 58%, along with half of all Git operations. GitHub credits the expanded footprint for absorbing growth in Actions job runs and for accelerating work on its largest monorepos, where the next target is an architecture whose read capacity scales linearly with reader count.
Operations Lagged the Growth
Fedorov concedes a second failure alongside the capacity one: as change accelerated, operational practice did not keep up. GitHub says it has moved teams onto availability work and invested in testing, safer rollouts, observability, and alerting, while isolating critical systems and cutting shared dependencies between them.
Two concrete changes came out of August. Retry limits, retry budgets, and variable timeouts are being standardized across service-to-service calls, aimed squarely at the storm behavior that prolonged the Copilot recovery. And low-priority CPU and memory alerts are under review to flag components likely to buckle during sudden spikes.
A Competitor Was Watching
Cursor launched Origin, its own code hosting product, on the morning GitHub went dark. Whether that timing was opportunism or coincidence, it made the commercial stakes legible: reliability is the entire value proposition of a platform that everything else depends on. With commits still climbing and the Azure migration incomplete, GitHub's fixes are racing the next peak.
