GitHub says its August 17, 2026 outage started as a capacity failure, then became harder to recover from when retry behavior multiplied traffic across already stressed systems. The incident lasted 7 hours and 47 minutes, from 13:28 to 21:15 UTC, and affected GitHub.com, APIs, pull requests, issues, Actions, authentication and Copilot.
GitHub’s August 20 reliability account describes the broader capacity problem and its planned response. GitHub’s detailed incident record supplies the technical sequence. Together, they show why autoscaling signals, retry policies and failover capacity must be designed as one system.
A sidecar limit escaped the autoscaling signal
The immediate failure occurred at load balancers in GitHub’s Central US hosting region during a new traffic peak. GitHub says an Istio sidecar pod reached its concurrency limit, but the associated autoscaling policy watched the host service rather than the sidecar’s limit.
That blind spot allowed capacity pressure to spread. Four HAProxy nodes eventually exhausted their flow limits, degrading a gateway authentication path and increasing authentication latency and failures across dependent services.
GitHub’s broader account classifies both its August 6 Actions outage and the August 17 incident as capacity failures, not incidents triggered by a new code or configuration change. That does not mean configuration was irrelevant. The incident record identifies the autoscaling policy as a material weakness, but the approved sources do not establish when that policy was introduced or last changed.
Retries became another source of load
During recovery, GitHub moved some failing traffic from Central US to Northern Virginia. That traffic was initially served successfully, but delayed responses from an internal endpoint exposed a latent retry bug in VS Code.
GitHub says the bug amplified affected traffic by approximately ten times. Copilot Token Service traffic rose from a normal 7,000–9,000 requests per second to 70,000–100,000 requests per second.
Retries inside GitHub also added pressure. Optimistic retry behavior overloaded internal load balancers, while repeated client token requests prolonged Copilot authentication failures after much of the platform had recovered.
GitHub also reported scraping attacks against codeload endpoints during the incident. It described those attacks as a complicating factor, not the initial cause of the outage.
Recovery differed across GitHub services
At peak, GitHub recorded error rates of approximately 20% for web and API traffic. Archive and raw-content downloads reached error rates of approximately 50%.
The blast radius extended beyond browsing repositories. SAML and OIDC authentication, SCIM provisioning and Team Sync were affected. GitHub Enterprise Cloud with Data Residency customers also saw affected Actions workflows when those workflows depended on public step definitions hosted on GitHub.com.
Most services had recovered by 16:36 UTC. Actions remained degraded until approximately 18:03 UTC, while Copilot Token Service did not fully recover until 21:02 UTC. GitHub marked the incident resolved at 21:15 UTC.
Growth explains the pressure, not the failure
GitHub says monthly commits increased from 1.4 billion in April to 2.9 billion by August. It also reports adding more than 3 million CPU cores, 120 petabytes of high-speed storage and substantial network capacity.
The company says Azure now serves roughly 58% of its platform load and half of all Git operations, compared with 12% of platform load in May. These are GitHub’s figures and were not independently audited in the approved source set.
The numbers provide context for the traffic pressure, but they do not demonstrate that additional infrastructure alone will prevent another cascade. The August 17 incident involved both insufficiently observed capacity and recovery behavior that generated more load.
GitHub’s follow-up work targets both problems
GitHub says it is correcting autoscaling policies so that service-mesh sidecar concurrency and capacity are included. It also plans to audit Istio request, concurrency and scaling limits across affected services.
Its retry work includes consistent limits, retry budgets, variable timeouts and a broader review of backoff behavior across gateways and clients. GitHub also says it will address the VS Code retry behavior, strengthen load-balancer capacity monitoring and improve regional failover safeguards.
The company’s wider reliability program includes isolating critical systems, removing shared dependencies, improving observability and eliminating architectural bottlenecks. These are commitments and work in progress, not evidence that the failure mode has already been removed across the platform.
What platform teams should take from the incident
The first lesson is to observe the component that can actually saturate. A healthy-looking host-service signal was insufficient when a sidecar enforced a lower concurrency boundary.
Second, retries consume capacity. Retry budgets and limits need to cover clients, gateways and service-to-service calls so that a partial recovery does not create a second traffic surge.
Third, regional failover must account for retry-amplified demand, not only normal request volume. Moving traffic helps only when the destination can absorb the requests and their recovery behavior.
Finally, dependency maps should include services that appear regionally or operationally separate. The impact on Data Residency Actions workflows shows how public workflow definitions hosted on GitHub.com remained a shared dependency.
What remains unverified
The internal mechanics and traffic figures come from GitHub’s own telemetry. ITPro’s independent report corroborates the published chronology and GitHub’s explanation, but it does not independently validate the company’s internal measurements.
GitHub has not provided completion dates for all long-term changes in the approved sources. It has also not published evidence that regional failover can now absorb the same retry pattern. Those improvements should therefore be treated as remediation commitments until later availability reports provide measured results.
