GitHub's Postmortem: 3 Million New CPU Cores and a Retry-Storm Confession After the 8-Hour Outage

GitHub has published the postmortem for its August 17 outage, and the diagnosis is uncomfortable: a critical component in its Central US data center simply failed to scale when traffic hit a new peak. The result was 7 hours and 47 minutes of degraded or dead service across github.com, authentication, Actions, pull requests, issues, the API, and Copilot.

The numbers were brutal. Error rates peaked at roughly 20% for web and API traffic and around 50% for archive and raw content downloads. More than 10,000 users flooded Downdetector at the worst moment. For teams that route deploys, CI, and code review through GitHub — which is most teams — the platform’s bad afternoon was everyone’s bad afternoon.

The root cause chain is a classic distributed-systems failure. Istio sidecar proxies that mediate inter-service communication hit their processing limits, but GitHub’s auto-scaling didn’t account for sidecar capacity, so nothing scaled. Then clients made it worse: retry loops — including from VS Code — hammered the recovering services and prolonged the incident. GitHub now admits it lacked consistent retry limits and budgets across its own stack.

This was also the second major incident of the month, after an Actions failure on August 6 that consumed nearly a full year’s error budget on its own. Two strikes in three weeks is what pushed GitHub to publish an unusually specific remediation plan rather than the usual “we take reliability seriously” paragraph.

The plan is enormous. GitHub is adding more than 3 million CPU cores and 120 petabytes of storage, and accelerating its migration to Azure — which will carry 58% of platform load, up from 12% in May. It’s implementing platform-wide retry budgets, isolating critical systems so a single component failure can’t cascade across every product, and redesigning read capacity for monorepos. CTO Vlad Fedorov didn’t hedge: “It is our responsibility to fix that. We’ll earn your trust through the scaling and reliability of the platform.”

The subtext worth reading: AI coding tools are a real infrastructure load, not a marketing line. Agents and assistants generate traffic patterns — constant polling, parallel clones, retry-heavy clients — that GitHub’s architecture wasn’t provisioned for. The platform that hosts the world’s code is being stress-tested by the tools writing it.

If your team’s incident response assumes GitHub is always up, this is your reminder to check what happens when it isn’t. Cache your dependencies, make CI failures distinguishable from outages, and know your deploy path when Actions is down. GitHub is spending billions so this doesn’t happen again. Your fallback plan costs an afternoon.

Sources

Related reading