The August 17 Outage, and the Work Ahead
GitHub's 7-hour-47-minute outage on August 17 had no bad deploy to blame — it was a capacity failure, the second such incident in two weeks, and GitHub's CTO explains what comes next.
When a major platform goes down for nearly eight hours, the instinct is to find the bad commit, the misconfigured rollout, the engineer who pushed on a Friday. GitHub’s August 17 outage had none of those. It was a capacity failure — no code changed, infrastructure simply failed to keep up with traffic.
Source
The August 17 outage, and the work ahead
By: GitHub
Published: Aug 20 2026
Type: Engineering article
Saved because this is one of the more direct post-incident accounts from a platform at this scale, the Copilot retry storm detail is a concrete production lesson, and the capacity framing — not code, not config — is a useful corrective for how most engineers think about outages.
Capacity failures don’t announce themselves in diffs
The August 17 outage lasted 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations trying to ship software that day. It was also the second significant incident within August — an Actions failure on August 6 had preceded it. In March and April, GitHub’s CTO Vlad Fedorov had published reliability commitments. These incidents made clear that the work needed to accelerate.
The root cause was not a deployment. Investigation found that traffic reached a new peak on August 17 and a critical infrastructure component in GitHub’s Central US data center failed to scale with it. The resulting capacity pressure spread through the system, causing authentication failures that cascaded into multiple services going down together.
The traffic context matters. From April to August, monthly commits on GitHub grew from 1.4 billion to 2.9 billion — a near-doubling in four months. Fedorov names this directly: the growth explains the pressure on the systems, but it does not excuse the outage. The failure is in the gap between infrastructure investment and demand. Capacity planning needs to stay ahead of the growth curve, not react to it.
Recovery required coordinated action across multiple teams: rerouting traffic, isolating affected infrastructure, and restoring services in stages. Most services came back earlier in the day, but Copilot services took longer. The reason is a useful production pattern. After the outage began, Copilot clients started retrying at higher rates, and that retry traffic increased load on the services teams were trying to restore. GitHub had to mitigate the retry loop before it was safe to bring traffic back. Without explicit retry budgets across service-to-service boundaries, a retry storm can turn a recovery window into a second incident.
Neither the August 6 nor August 17 outage was caused by a code or configuration change. Both were capacity failures at their core. That distinction matters because it changes what you look for when the next one happens.
GitHub had been investing in infrastructure before these incidents. Since earlier in the year, they added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. Azure now serves roughly 58% of GitHub’s platform load and half of all Git operations, up from 12% of platform load in May. That expanded footprint has supported the growth in GitHub Actions job volume. For the largest monorepos specifically, the next milestone is an architecture that scales read capacity linearly with the number of readers — a design change that removes the ceiling on read-heavy workloads rather than raising it.
Two immediate technical changes followed directly from the August incidents. First, GitHub is applying consistent retry limits, retry budgets, and variable timeouts across all service-to-service interactions. This is the direct response to the Copilot retry storm: with explicit budgets and timeouts, a retry loop cannot grow unbounded during a recovery window. Second, GitHub is reviewing lower-priority CPU and memory alerts to find components that could fail silently under sudden traffic spikes before they cascade into user-visible impact.
Beyond those immediate fixes, the post covers two structural directions. The team is isolating critical systems from each other and removing shared dependencies between them. The design goal is that a failure in one service should not propagate to unrelated services — limiting blast radius when an outage does happen. Separately, Fedorov acknowledges that operational practices have not kept pace with the speed and complexity of change at GitHub: stronger testing, safer rollouts, better observability, and more effective alerting are all named, with an honest admission that this work is not finished.
The post closes with a direct statement: the developer community depends on GitHub to build, ship, and operate their work, and on August 17, that dependence was broken. There is no language about how rare this was or how many nines GitHub normally achieves. The commitment to fix it is framed in terms of demonstrated reliability, not planned improvements.
My take
The Copilot retry storm detail is the part I’ll use most directly. When you’re designing retry logic, the failure case is usually framed as the service being slow or unavailable. This incident is a reminder that clients retrying aggressively during an outage can actively prevent the recovery — the load they generate may exceed what the recovering infrastructure can safely absorb. Retry budgets and variable timeouts are not just cost-control measures; they are what allows a platform to actually complete a recovery. The capacity framing is also worth sitting with: this outage had no deploy to roll back, no bug to patch. The fix is infrastructure investment that stays ahead of growth, which is a different kind of problem.
Where this is useful
- Designing retry logic and circuit breakers in distributed systems where the Copilot retry storm pattern is a concrete failure mode to defend against
- Capacity planning conversations where historical growth rates are underestimated or used as the only input
- When NOT applicable: diagnosing outages caused by code changes, configuration drift, or bad deployments — this was specifically a no-change capacity failure with a different root cause analysis process
Apply this: Add retry budgets and variable timeouts to every service-to-service call before you need to survive your next traffic spike.
What I want to remember
Remember: Traffic spikes expose capacity gaps that normal load keeps hidden.