GitHub suffered a major service disruption lasting 7 hours and 47 minutes on August 17, beginning at 1328 UTC and extending until 2115 UTC. The outage affected core developer services including Issues, Pull Requests, APIs, Actions, and Copilot, leaving many organizations unable to work normally. The incident began when network saturation hit load balancers in GitHub's Central US facility after an Istio sidecar reached its concurrency limit.
The root cause involved multiple technical failures working in combination. A misconfigured autoscaling policy monitored the host service but failed to track the sidecar's concurrency limit, preventing the system from automatically adding capacity when needed. This allowed a cascading failure to develop across the infrastructure. The situation deteriorated further due to optimistic retry logic that overloaded internal load balancers, creating a feedback loop of failed requests and retries.
A particularly problematic factor emerged from Visual Studio Code's interaction with Copilot services. Delayed replies to a single internal endpoint triggered a latent retry bug in VS Code that amplified traffic by approximately 10x, significantly delaying recovery for the Copilot Token Service. Engineers initially mitigated the problem by temporarily reducing gateway retries through code changes and configuring load balancers to reject inbound Copilot Token Service requests with HTTP 403 responses. GitHub also noted that scraping attacks on codeload endpoints complicated recovery efforts.
Most services returned to normal operation by 1636 UTC, with Actions recovering by 1803 UTC. However, the Copilot Token Service remained impaired until 2102 UTC, making it the last component to fully recover. The extended downtime affected developers globally who rely on GitHub for version control, collaboration, and AI-assisted coding through Copilot.
GitHub has committed to several remediation measures including correcting autoscaling policies, reviewing retry limits across services, auditing Istio concurrency settings, and addressing the VS Code behavior that amplified token traffic. The incident has prompted industry discussion about platform reliability and alternatives, with competitors like Cursor announcing new code hosting services during the outage. Organizations dependent on GitHub should review their contingency plans and consider whether backup access to repositories through alternative methods would help maintain operations during future incidents.
Source: https://www.theregister.com/saas/2026/08/19/github-blames-8-hour-outage-on-autoscaling-fail-and-vs-code-retry-storm/5289547