GitHub published its account of the August seventeenth outage on Thursday, and the root cause is one of the more instructive failures we have read this year. Nothing shipped. No configuration changed. Traffic reached a new peak, an Istio sidecar proxy in the Central US data centre hit its concurrent processing ceiling, and the autoscaler watched only the primary container beside it and saw nothing worth acting on. What followed was seven hours and forty seven minutes of degraded service, made considerably worse by a retry defect in Visual Studio Code that pushed one authentication service from around nine thousand requests per second to a hundred thousand.
The short answer
GitHub CTO Vladimir Fedorov published the August seventeenth postmortem on Thursday, August twentieth. An Istio sidecar proxy in the Central US data centre reached its concurrent processing limit as traffic hit a new peak, and the autoscaling rules only watched the primary container, so nothing scaled. Saturation spread to the HAProxy tier and knocked over internal authentication. A retry defect in Visual Studio Code then took the Copilot token service from 9,000 requests per second to 100,000, which delayed recovery further.
Most public postmortems tell you which change broke production. This one tells you that nothing changed, which is the version that should worry anybody running a service mesh.
The component nobody was scaling on
GitHub runs its services with Istio, so a request between two internal services does not go straight from one application container to another. It passes through a sidecar proxy running in the same pod, which handles routing, retries, telemetry and mutual authentication on the application's behalf.
On August seventeenth, traffic reached a new peak and that sidecar reached its concurrent processing limit in the Central US data centre. The autoscaling rules were reading the state of the primary service container, not the sidecar next to it, so the pods looked healthy and no expansion was triggered.
This is the part worth sitting with. The application was fine. The metric everyone trusted was fine. The thing actually carrying every request had run out of headroom, and it was invisible to the control loop responsible for adding more of it.
Saturation then moved outward. The HAProxy load balancers in front hit their own processing limits, internal authentication paths became unreliable, and because nearly every GitHub surface authenticates against those paths, the failure presented as everything being slightly broken at once rather than one service being down.
The retry storm sitting on top of it
Recovery was not a matter of adding capacity and walking away, because a client side defect was actively fighting the restoration.
Visual Studio Code retried aggressively when Copilot authentication failed, without effective backoff. Every editor that hit an error came straight back for another attempt. GitHub puts the numbers plainly: the service handling Copilot authentication tokens normally sees 7,000 to 9,000 requests per second, and during the incident it saw 70,000 to 100,000.
A tenfold amplification arriving precisely when a service is least able to answer is the classic retry storm, and it is self sustaining. The failure generates the load that prevents the failure from ending. GitHub had to mitigate the retry behaviour before it could safely route traffic back, which is why Copilot took longer to return than the rest of the platform.
If you write clients, this is the reminder to check what yours does on a 5xx. A retry without a budget is not resilience, it is a load multiplier that only activates during incidents.
The growth numbers explain the shape of the problem
The postmortem includes figures that are unusual to see published, and they reframe the incident as something other than carelessness.
Monthly commits went from 1.4 billion in April to 2.9 billion in August. Actions job runs reached 115.4 million by August. Azure now serves roughly 58 percent of GitHub's platform load and half of all Git operations, against 12 percent of platform load in May.
Those are not gentle curves. A platform that doubles its write volume in four months while migrating a majority of its load to a different substrate is going to discover ceilings, and it will discover them in the components nobody thought to instrument. Fedorov is direct that neither the August seventeenth incident nor the August sixth Actions degradation was caused by a code or configuration change. Both were capacity failures.
What GitHub is committing to
The remediation splits into capacity, retry discipline and blast radius.
On capacity, more than 3 million CPU cores, 120 petabytes of high speed storage and additional network capacity have been added, with the Azure migration accelerated.
On retries, consistent retry limits, retry budgets and variable timeouts are being applied across service to service interactions specifically to stop retry storms and cascading load. That is the correct lesson from the Copilot token numbers, and it applies to the internal mesh as much as to the editor.
On blast radius, GitHub is reviewing lower priority CPU and memory alerts to find components that can fail during sudden spikes, and isolating critical systems so shared dependencies cannot take several products down together.
What we would take from this
Three things transfer directly to smaller estates.
Scale on the thing that saturates, not the thing you named. If you run a service mesh, your horizontal pod autoscaler is probably reading CPU on the application container. The proxy has its own concurrency limit, its own connection pool and its own metrics, and Envoy exposes them. An HPA that cannot see the proxy will happily watch a pod suffocate.
Give every retry a budget. Retry limits alone are not enough, because a limit still permits every client to retry simultaneously. A budget caps retries as a fraction of total requests, so amplification stays bounded no matter how many callers are failing at once.
Treat your low priority alerts as a capacity backlog. GitHub is explicitly going back through alerts it had deprioritised to find the components that could fail under a spike. Most teams have that same list, quietly firing every few weeks and quietly being dismissed. Somewhere in it is the sidecar.
Sources and further reading
- The August 17 outage, and the work ahead, The GitHub Blog, August 20, 2026
- GitHub's ~8-Hour Outage Caused by Capacity Shortage, BigGo Finance, August 2026
- GitHub now sees 2.9 billion commits a month, The New Stack, August 2026
- GitHub Status
Frequently asked questions
What exactly failed during the August 17 GitHub outage?
A sidecar proxy did. GitHub runs Istio, so most service to service traffic passes through a sidecar container sitting next to the application container in the same pod. When request volume reached a new high, that sidecar reached its concurrent processing limit. The autoscaling rules were watching the primary service, not the sidecar, so from the scheduler's point of view nothing was under pressure and no new capacity was added. The saturation then propagated outward to the HAProxy load balancers, which hit their own processing limits and destabilised the internal authentication paths that almost everything else depends on.
How long was GitHub down and what was actually broken?
The incident ran seven hours and forty seven minutes on August seventeenth, 2026, roughly 13:28 UTC to 21:15 UTC. It was degradation rather than a clean outage, which is often worse to work through. Error rates sat near twenty percent for the web experience and the API, and near fifty percent for archive downloads and raw repository content. Authentication, Actions, pull requests, issues and Copilot were all affected. The uneven error rate is why so many people reported that GitHub was up for a colleague and down for them.
What did Visual Studio Code have to do with it?
It turned a bad hour into a much longer one. A defect in Visual Studio Code retried aggressively when Copilot authentication failed, with no meaningful backoff. Every editor session that hit an error came straight back, so the service issuing Copilot authentication tokens went from a normal 7,000 to 9,000 requests per second to between 70,000 and 100,000. That is a client side retry storm, and it is self sustaining: the load caused by the failure prevents the recovery that would end the failure. GitHub had to suppress the retry behaviour before it could safely restore traffic.
Was this caused by AI agents hammering the platform?
Not directly, but the growth curve behind it is hard to separate from automated tooling. GitHub says monthly commits went from 1.4 billion in April to 2.9 billion in August, and Actions job runs reached 115.4 million by August. Azure now carries roughly 58 percent of platform load and half of all Git operations, up from 12 percent in May. The company is explicit that neither this incident nor the August sixth Actions degradation came from a code or configuration change. Both were capacity failures, which is a different class of problem and a harder one to test for.
What is GitHub changing to stop it happening again?
Three strands. First, raw capacity: more than 3 million CPU cores, 120 petabytes of high speed storage and additional network capacity have already been added, alongside an accelerated Azure migration. Second, retry discipline, with consistent retry limits, retry budgets and variable timeouts applied across service to service calls so a partial failure cannot amplify itself. Third, observability and blast radius, meaning a review of lower priority CPU and memory alerts that could have flagged the saturating component earlier, plus isolating critical systems and removing shared dependencies between them.