Tech and AI
GitHub's chief technology officer says both August outages were capacity failures rather than faults introduced by a change
By Staff Writer | 22 August 2026
Vladimir Fedorov published an account on 20 August of the outage three days earlier, which lasted 7 hours and 47 minutes and took down the site, authentication, Actions, pull requests, issues, Copilot and the interfaces. He says neither that incident nor the one on 6 August was caused by a code or configuration change, and that monthly commits have risen from 1.4 billion in April to 2.9 billion.
The distinction he draws is the one that matters to anyone who runs a platform under a contract. A deployment that breaks something can be rolled back, and the incident closes when it is. A capacity failure is different: the weakness is already in the system, nobody put it there on the day, and it surfaces only when traffic finds it.
If you were trying to ship software that day, we let you down.
Vladimir Fedorov, Chief Technology Officer at GitHub
What the account says happened
Traffic reached a new peak and a critical infrastructure component in the company's Central US data centre failed to scale with it. The capacity pressure spread outward, authentication began failing, and multiple services went with it. Recovery took several coordinated steps: traffic was rerouted, the affected infrastructure was isolated, and services were brought back in stages. Most came back the same day. Some of the Copilot services took longer, and errors in those services set off a retry loop on the client side that pushed traffic up again during the recovery itself, so that behaviour had to be damped before load could safely be restored.
The numbers behind the pressure
Monthly commits have gone from 1.4 billion in April to 2.9 billion. Against that, the company says it has added more than 3 million CPU cores and 120 petabytes of high speed storage, and installed as much hardware as the available power in its existing data centres allowed. The monthly volumes now also run to about 24 million new repositories and 130 million merged pull requests.
Where the power ran out, the work moved. Azure now serves roughly 58 per cent of the platform load and half of all Git operations, against 12 per cent of platform load in May. That is a fast migration by any standard, and it is being run at the same time as the platform is failing under load, which is the least comfortable moment to move anything.
Our next milestone is an architecture that scales read capacity linearly with the number of readers, enabling unlimited read operations.
Vladimir Fedorov, Chief Technology Officer at GitHub
What changes before that arrives
Two changes come out of the two incidents directly. Retry limits, retry budgets and variable timeouts are being applied consistently across service to service calls, which is the guard against the retry storm that made the 17 August recovery worse. Lower priority processor and memory alerts are being reviewed to find components that could fail during a sudden spike, which is the guard against the failure being noticed only once it has spread. Separately, critical systems are being isolated from one another so that a failure in one does not reach the rest.
The candour is worth something. So is the admission, made twice in the same post, that the operating practices did not keep pace with the rate of change. Anyone whose delivery programme depends on this platform now has a written statement that the capacity work is unfinished, and a date for none of it.