GitHub CTO Vlad Fedorov’s postmortem for the August 17 outage — 7 hours 47 minutes that disrupted github.com, authentication, Actions, APIs, pull requests, issues, and Copilot. The headline finding: neither this incident nor the August 6 Actions failure was caused by a code or configuration change. Both were capacity failures.

What happened:

  • Traffic hit a new peak and a critical Central US data center component failed to scale with it; the capacity pressure spread and caused authentication failures that cascaded across services.
  • Recovery needed coordinated rerouting, isolation, and staged restoration — and a client-side retry loop in Copilot services added traffic during recovery and had to be mitigated first.
  • The scale context: monthly commits grew from 1.4 billion to 2.9 billion since April, alongside roughly 130M merged PRs and 24M new repositories per month.

The work ahead:

  • Three priorities — capacity, efficiency, removing architectural bottlenecks. Already added 3M+ CPU cores, 120PB of storage, and significant network capacity.
  • Azure now serves about 58% of platform load and half of all Git operations, up from 12% in May.
  • Next milestone: an architecture that scales read capacity linearly with readers for the largest monorepos, rolled out gradually.
  • Isolating critical systems and removing shared dependencies between them, to shrink both the likelihood and the blast radius of outages.

Two immediate changes came out of the August incidents: consistent retry limits, retry budgets, and variable timeouts across service-to-service calls — to prevent retry storms — plus a review of lower-priority CPU and memory alerts to catch components that fail under sudden traffic spikes.

The pattern is the lesson: modern outages increasingly come from scale, not bad deploys. Retry storms add load exactly when capacity is tight, and shared dependencies turn one component into a platform-wide incident. The candor — “if you were trying to ship software that day, we let you down” — and the concrete numbers make this a useful reliability case study, not a generic apology.