The outage that hit GitHub.com on August 17 began with network saturation in the Central US region and dragged out the recovery of both the authentication path and the Copilot Token Service. GitHub reported the incident resolved at 21:15 UTC that same day, putting the total impact duration at 7 hours and 47 minutes. According to the company's incident report, the root cause was a combination of auto-scaling that failed to account for sidecar concurrency limits and a surge in retries triggered by failures. A monitoring gap in a shared path cascaded into both authentication and client-side retries.
7 Hours 47 Minutes: From the Developer Front Door to Authentication
The impact began at 13:28 UTC on August 17, 2026 — 22:28 JST on the 17th through 06:15 JST on the 18th. GitHub's first status update came at 13:40 UTC, meaning the actual user impact started 12 minutes before the initial report. At its peak, Web and API error rates reached roughly 20%, while archive and raw content downloads saw failure rates of about 50%. Issues, Pull Requests, and the API were affected, along with Actions and Copilot. Git Operations, Webhooks, and Pages were also impacted.
The authentication path was affected as well. SAML/OIDC authentication, SCIM, and Team Sync experienced delays and failures, disrupting organization user management. Actions workflows for GitHub Enterprise Cloud with data residency, which depend on public workflow step definitions hosted on GitHub.com, were also affected. In GitHub Actions, since each job's steps within a workflow execute the user's scripts or reusable Actions, an outage in the GitHub.com reference source can ripple into execution even within a dedicated environment.
Most services recovered by 16:36 UTC, but degradation in Actions persisted until around 18:03 UTC. The Copilot Token Service did not fully recover until 21:02 UTC — a gap of 4 hours and 26 minutes between the first major recovery and Copilot's complete restoration.
A Sidecar Monitoring Gap Cascaded into Four HAProxy Nodes
The immediate cause was network saturation at load balancers in the Central US data center, triggered by a new traffic peak. At the root of it, Istio sidecar pods hit their concurrency limits. The auto-scaling policy was monitoring the host service but not the sidecar's limits, so it failed to scale correctly at the critical moment.
According to GitHub, the failure cascaded further, ultimately exhausting the flow limits on four HAProxy nodes. Delays and failures spread through the gateway's authentication path, and overly optimistic retry logic overloaded internal load balancers, worsening the situation. Once all four HAProxy nodes were simultaneously paused, broad service recovery followed immediately. However, GitHub has not disclosed the capacity or flow limits of each node, the specific concurrency limit for the Istio sidecars, or the misconfigured value.
100,000 Requests per Second: Retries Delayed Copilot's Recovery
In the Copilot Token Service, failed token operations were capable of generating additional requests and retry loops. Traffic that normally ran at 7,000–9,000 requests per second surged to 70,000–100,000 requests per second during the incident. GitHub described this as roughly a 10x amplification. The company also cited a potential retry bug in VS Code — triggered by delayed responses from a single internal endpoint — as a factor that increased traffic and delayed recovery.
The residual impact varied by client. In updates at 20:08 UTC and 20:45 UTC, GitHub noted that intermittent Copilot authentication failures continued for some applications, while Copilot usage via the GitHub CLI and GitHub App remained unaffected. At least at that point, the scope of Copilot's impact diverged depending on the client path.
In response to the retry storm occurring in North Virginia, GitHub temporarily reduced the gateway's retry logic via a PR. It also had the load balancer block incoming token requests to the Copilot Token Service with 403 responses, then gradually restored traffic on a per-site basis. GitHub has not stated that the 403-based blocking, an emergency measure, was adopted as a permanent solution. The VS Code fix PR, the affected versions, and the timeline for the fix's release remain undisclosed.
Lingering Dependencies After the Failover to North Virginia
During recovery, GitHub redirected a portion of the failing traffic from Central US to North Virginia, where it was processed normally until the Central US network failure was investigated and resolved. However, this was not reported as a full failover — it was limited to "a portion of the failing traffic." Multiple scraping attacks against the codeload endpoint also complicated the recovery, though GitHub did not identify these as a direct cause. The company has not disclosed what share of the new traffic peak was attributable to normal usage, retries, and scraping attacks respectively.
The remediation measures GitHub outlined include revising auto-scaling configurations to account for sidecar concurrency capacity, auditing Istio's request count, concurrency, and scaling limits, and reviewing retry limits and backoff settings for both gateways and clients. The company will also address the amplification behavior in VS Code. Improvements to load balancer capacity monitoring and regional failover protection are also planned.
Measuring resilience requires more than checking normal-time headroom — it also demands verifying retry design for when dependencies are delayed. How many times, and at what intervals, do clients and gateways resend requests? Whether those limits can be validated under real failure conditions will determine the length of the next recovery.