Lessons from August 17 Outage: How Capacity

At 13:28 UTC on August 17, 2026, GitHub began a 7 hour and 47 minute service disruption that touched nearly every surface developers touch in a day: the web interface, authentication, APIs, pull requests, issues, Actions, and Copilot. At peak, web and API traffic ran at roughly 20% error rates while archive and raw content downloads failed at about 50%. By the time the last Copilot service recovered at 21:02 UTC, GitHub’s CTO was on the blog admitting what the incident data made plain: the platform’s reliability work had not kept pace with its own growth.

This was the second significant incident of the month, and unlike a config typo or a bad deploy, it was driven at its core by capacity. GitHub’s engineering leadership now frames the summer of 2026 as a forced reckoning with scale, and the fixes they describe go far beyond patching one autoscaling policy.

The scale of the disruption

GitHub confirmed the outage worldwide at 9:40 AM EDT on August 17, according to Bleeping Computer. Within minutes, the status page marked API Requests, Actions, Webhooks, Issues, and Pull Requests as degraded, and Copilot joined the list before mid-morning local time. The official incident report records the duration as 13:28 to 21:15 UTC, a total of 7 hours and 47 minutes.

The pattern: two capacity failures in two weeks

Most of the platform recovered earlier in the day. The status report shows most services back by 16:36 UTC as the Central US datacenter recovered, with Actions degraded until roughly 18:03 UTC and the Copilot Token Service fully recovered only by 21:02. That long tail came from how the systems interacted during mitigation, rather than from the initial failure alone. For a platform that a Bleeping Computer commenter called the place where “the whole routine of coding happens,” the weekend disruption hit a wide surface: authentication, code review, CI/CD, and AI assistance all went down together.

The incident did not happen in isolation. GitHub experienced eight incidents that degraded its services during July, following nine in May and six in June, and had already suffered a substantially disruptive Actions failure on August 6. That context matters for reading the August 17 event: it is the worst day in a reliability slide, and it follows a pattern rather than breaking one.

What happened: a capacity failure, not a code change

GitHub’s engineering team determined that neither the August 6 nor the August 17 incident was caused by a code or configuration change, according to CTO Vlad Fedorov’s post published August 20. “Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity.”

The specific chain of events, from the root cause analysis, is a textbook example of how a small hardware and configuration problem becomes a platform-wide outage:

A new peak in traffic saturated load balancers in the Central US datacenter.
An Istio sidecar pod reached its concurrency limit and failed to autoscale because the scaling policy watched the host service’s limits but not the sidecar’s.
The failure cascaded until four HAProxy nodes exhausted their flow limits, degrading the gateway auth path and causing widespread authentication latency and failures.
The problem was amplified by optimistic retry logic that overloaded internal load balancers.

The immediate cause was a capacity ceiling hit at the wrong moment, compounded by a monitoring blind spot: the autoscaling policy that should have been watching the sidecar’s concurrency was reading the wrong metric. The recovery was equally telling. Pausing HAProxy on those nodes simultaneously produced immediate broad recovery, which is why most services were steady again by mid-afternoon UTC.

The growth behind the demand is stark. Fedorov reports that monthly commits have grown from 1.4 billion to 2.9 billion since April. That is a doubling in roughly four months, pressure that any platform would struggle to absorb without significant capacity work in place ahead of time. GitHub’s own merged-pull-request counts, commit counts, and new-repository counts all show sharp acceleration through 2025 and 2026. The scale is itself the story: a system engineered for the previous plateau is now running in a regime where old assumptions about peak traffic no longer hold.

The retry storm that delayed recovery

The most instructive part of the incident for any SRE is how recovery itself became a new source of load. The root cause analysis describes a latent retry bug in VS Code that amplified Copilot traffic by approximately 10 times once delayed replies from a single internal endpoint arrived late. Failed Copilot token operations generated many extra requests and looped.

The numbers are striking. Copilot Token Service traffic jumped from a normal 7,000 to 9,000 requests per second to 70,000 to 100,000 requests per second during the storm. That deluge is what kept several Copilot services down well after the underlying network failure was resolved. The team could not simply restore traffic; it had to first break the retry loop by reducing gateway auth retries and selectively returning 403 responses to block retry-triggering calls, then ramp traffic back up slowly per site.

The retry storm is the detail most teams should study. On August 17, engineers on the GitHub side had to pause the retry-inclined behavior of software it distributes, the VS Code extension, mid-crisis. That is a sharp reminder that retries are a distributed system tool that behaves like a resource: bounded, budgeted, and consistent across service boundaries. GitHub now knows firsthand the cost of optimistic retries with no global cap. A problem that began as one concurrency limit quickly became a platform-wide authentication failure precisely because retries were scattered and uncoordinated.

There was a secondary aggravating factor: scraping attacks on codeload endpoints, which impeded recovery. That layers an adversarial traffic source on top of organic demand growth, raising the bar for what “capacity” has to accommodate.

The pattern: two capacity failures in two weeks

August 17 followed August 6, when GitHub Actions suffered a lengthy disruption in which workflow runs failed or remained queued for hours. TechSpot reported the company called that earlier outage unacceptable and said it was accelerating work to improve isolation and resiliency within Actions. That the follow-on incident was even broader is the worry: rather than being contained to one service, the August 17 failure touched APIs, auth, collaboration, and AI simultaneously.

GitHub’s own availability reporting quantifies the slide. The platform logged eight incidents in July alone that degraded service quality, after nine in May and six in June. Independent tracking reinforces the point: one report found GitHub Actions uptime fell to 99.33% over a 90-day window, and that the single August 17 outage consumed almost an entire year’s downtime budget for the service. Whether a given large outage is isolated or system-wide, the shared pattern is the same: demand outgrew provisioned capacity, and the safety mechanisms meant to absorb a spike were not watching the right signals.

Month	Degraded incidents	Source
May 2026	9	TechSpot
June 2026	6	TechSpot
July 2026	8	TechSpot

The frequency is itself data. A platform that serves hundreds of millions of developers does not normally produce six, eight, or nine degraded incidents a month. The fact that this cadence persisted through May, June, and July, then was followed by two major August failures, is the clearest signal that the workload growth is not a temporary surge. It is the new baseline, and the platform’s reliability engineering has to catch up to it.

The work ahead: capacity, isolation, and retry discipline

Fedorov’s post outlines the reliability program already underway, organized around three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks. The capacity numbers are large. GitHub says it has added more than 3 million CPU cores and 120 petabytes of high-speed storage, plus significant network capacity, while installing as much hardware as available power in existing datacenters would allow.

The clearest structural change is the accelerated migration to Azure. Fedorov reports that 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 shift is meant to reduce shared failure points and make a single datacenter’s trouble easier to contain, rather than letting one region’s auth path take the whole platform down. It is also tied to GitHub’s next scaling milestone: architecture that scales read capacity linearly with the number of readers, to enable effectively unlimited read operations, rolling out gradually beginning with the largest monorepos.

Capacity alone does not solve the reliability problem, and Fedorov admits the operational practices have not kept up with the pace and complexity of change. The work in that bucket is unglamorous: stronger testing, safer rollouts, better observability, more effective alerting, and isolating critical systems so shared dependencies fail less often and cause less blast radius when they do.

The August incidents produced two immediate changes, both directly aimed at what went wrong on the 17th. First, GitHub is applying consistent retry limits, retry budgets, and variable timeouts across service-to-service interactions to prevent exactly the kind of retry storm that hit Copilot. Second, it is reviewing lower-priority CPU and memory alerts to identify components that could fail during sudden traffic spikes, the same blind spot where the misconfigured autoscaling policy lived. The stated intent is to stop writing postmortems for incidents that are capacity failures waiting to happen.

What teams should do now

For organizations that build on GitHub, the outage is a reminder that the platform is a dependency, and every dependency has failure modes. The practical response is to build the same resilience into your own workflows that GitHub is trying to build into its platform, rather than to flee GitHub entirely.

Match the retry discipline GitHub is adding. If a platform-side retry storm can multiply Copilot traffic by 10 times, imagine what your own agents and CI jobs do when the service is slow. Standardize retry budgets, cap backoff, and add jitter. The lesson of August 17 is that optimistic retries without a global limit do not make a system more reliable. They make a partial failure become a total one.

Keep mission-critical automation on a path you can operate without the hosted platform. GitHub itself recommends diversifying CI/CD so one outage does not stall a release. Maintain local mirrors and cached dependencies, keep a recent clone of critical repositories, and make sure the deployments that gate a release do not depend on a single vendor’s hosted runtime that may be down at the exact moment you need it.

Treat status pages and error budgets as inputs to release planning. The 90-day Actions uptime of 99.33% is a number to weigh actively, in the same way we discussed in our coverage of platform reliability and migration strategies in 2026. When a dependency’s incident cadence rises to multiple degraded days a month, teams should decide explicitly where they are willing to couple their release process to that availability, and where they will hold final control.

Key takeaways

The August 17 outage lasted 7 hours and 47 minutes and hit web, auth, API, pull requests, issues, Actions, and Copilot at once.
At peak, web and API error rates reached roughly 20%; archive and raw content downloads failed at about 50%.
The root cause was a capacity failure, not a code or config change: network saturation on Central US load balancers, triggered by a misfiring autoscaling policy that ignored sidecar concurrency.
A latent VS Code retry bug amplified Copilot traffic by about 10x, pushing the token service from 7-9K to 70-100K requests per second and delaying recovery beyond the initial fix.
GitHub’s work ahead adds capacity (3 million+ CPU cores, 120PB of storage), accelerates the Azure migration (now ~58% of platform load), isolates critical systems, and enforces consistent retry budgets and timeouts.
For teams, the practical response is matching that retry discipline, keeping critical paths off single-vendor hosted runtimes, and treating the platform’s error budget as an input to release planning.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article: