GitHub blames 8-hour outage on autoscaling fail and VS Code retry storm
GitHub has published a post-incident report attributing this week's near eight-hour outage to a chain of infrastructure failures rather than a single cause. The company traced the problem to saturated load balancers in its Central US facility, a misconfigured autoscaling policy that failed to monitor a key concurrency limit, and a previously unknown retry bug in Visual Studio Code that massively amplified traffic to its Copilot Token Service, delaying recovery. The incident matters because it left developers unable to work normally across core GitHub services for hours, adding to a string of recent reliability problems and prompting renewed talk of rivals such as Cursor.
The outage began at 1328 UTC on 17 August and was not fully resolved until 2115 UTC, lasting seven hours and 47 minutes and causing elevated errors across Issues, Pull Requests, APIs, Actions and Copilot. An Istio sidecar hit its concurrency limit, but the autoscaling policy watched only the host service, not the sidecar, letting a cascading failure develop that was worsened by overly aggressive retry logic; engineers mitigated it by cutting gateway retries and blocking inbound Copilot Token Service requests. Most services recovered by 1636 UTC and Actions by 1803 UTC, but the Copilot Token Service, hit by a VS Code bug that amplified traffic roughly tenfold, was not fully restored until 2102 UTC, with recovery further hampered by scraping attacks on codeload endpoints; GitHub says it will fix the autoscaling policy, review retry limits and address the VS Code issue.
- GitHub outage lasted almost 8 hours on 17 August 2026
- Cause: bad autoscaling policy plus VS Code retry bug
- Copilot Token Service hit hardest, recovered last
New here? Start with this
GitHub is a service developers use to store and manage code, work together on software and run automated tasks. Visual Studio Code is a widely used code editor, and Copilot is GitHub’s AI assistant for writing and explaining code.
GitHub’s services rely on networks of servers that handle requests and spread work as demand changes. When one part cannot keep up, automatic scaling and retrying failed requests can affect other parts too.
The incident disrupted tools developers use to collaborate, build and access AI assistance. It has drawn attention to GitHub’s reliability and to other coding tools that developers might consider.
Both sides, in good faith
The strongest fair case each way — we don't pick a winner.
The case for
GitHub's reliability problems have become unacceptable for mission-critical infrastructure. The root causes reveal preventable failures: a misconfigured autoscaling policy that failed to monitor a critical resource limit, overly aggressive retry logic that amplified traffic tenfold, and lack of visibility into dependencies like the undetected VS Code bug. The pattern of recent outages suggests systemic engineering failures rather than isolated incidents, and developers cannot afford repeated 8-hour disruptions caused by preventable oversights.
The case against
Distributed systems at scale inevitably face novel failure modes that cannot be fully predicted in advance. GitHub's response was strong: engineers identified root causes promptly, resolved the incident cleanly without data loss, and are implementing fixes for problems both within their control and beyond it. One significant outage per year across billions of monthly interactions represents solid reliability overall, and GitHub's transparency in post-mortems demonstrates mature engineering and helps the entire industry improve.