◆ GENERAL · Big Story
GitHub's autoscaler was watching a number that could not see the thing filling up.
GitHub.com was degraded for 7 hours 47 minutes on August 17. Copilot stayed broken for four and a half of them, because a retry bug in VS Code kept hitting the service that had just come back.
Chandni Melwani
Founder & Editor
Aug 22, 2026 · 2 MIN READ
The News
GitHub.com ran degraded for 7 hours and 47 minutes on August 17, 2026, from 13:28 to 21:15 UTC. At peak, GitHub says web and API error rates were approximately 20%, and archive and raw-content downloads reached approximately 50%. In an incident thread published August 18, GitHub says the immediate cause was network saturation on load balancers in its Central US data center after traffic hit a new peak. Most services recovered by 16:36 UTC. Copilot did not recover until 21:02 UTC, because a retry bug in VS Code amplified traffic at the service that issues Copilot tokens by roughly 10x while it was trying to come back.
Know More
- — The window: 13:28 to 21:15 UTC on August 17, 2026, 7 hours 47 minutes. Central US recovered around 16:36 UTC, Actions around 18:03 UTC, the Copilot Token Service at 21:02 UTC.
- — The scaling gap: GitHub's incident thread says an Istio sidecar, the proxy that sits beside each service and handles its network traffic, hit its concurrency limit under a misconfigured policy that watched host service but not sidecar limits, so it never scaled.
- — The cascade: that exhausted flow limits on four HAProxy load-balancer nodes and degraded the gateway authentication path, which is why sign-in-dependent services went with it.
- — The amplification: GitHub says delayed replies to one internal endpoint triggered a latent retry bug in VS Code that multiplied traffic by approximately 10x, taking the Copilot Token Service from 7-9K requests per second to 70-100K. GitHub also lists a second factor that impeded recovery: scraping attacks on its codeload endpoints.
- — The caveat: both accounts are GitHub's own — the incident thread the day after the outage, the company blog three days after. No independent review has been released, and GitHub's company blog does not name any of the components above.
Most of GitHub was working again by 16:36 UTC on August 17. Copilot was not, and stayed broken for another four and a half hours, because the editor kept asking.
GitHub’s company blog, published three days later, says traffic reached a new peak and “a critical infrastructure component in our Central US data center failed to scale.” The incident thread is where the mechanism sits. An Istio sidecar, the proxy that carries a service’s network traffic, filled up to its concurrency limit while the autoscaling policy watched host service capacity instead. The rule meant to add capacity was reading a gauge attached to something that was not the thing running out. Four HAProxy nodes then exhausted their flow limits, the gateway authentication path degraded, and everything needing a sign-in went with it.
Then the AI tooling made it worse. Slow replies from one internal endpoint, GitHub says, “triggered a latent retry bug in VS Code that amplified traffic by approximately 10x” at the Copilot Token Service, taking it from 7-9K requests per second to 70-100K. A service already struggling got ten times its normal load from clients that were, by design, trying to be helpful.
Retry storms are old news in distributed systems and the defences are well known. What is newer is the shape of the client. An AI coding assistant sits on millions of desktops, talks to a small number of authentication endpoints, and retries on the user’s behalf without the user knowing it is happening, which makes an editor fleet behave like a load generator with no operator. GitHub says it is addressing the VS Code retry behaviour. Anyone else shipping an AI client that phones home to a token service — Meta’s WhatsApp agent, the ad-serving stack behind ChatGPT — now has a documented example of what its own retry policy is worth reading for. The accounting is GitHub’s own on both counts, and the company blog it published three days later names none of the components the incident thread does.
Related
Frequently Asked Questions
Why did Copilot stay down after the rest of GitHub came back?
GitHub's incident thread says a latent retry bug in VS Code responded to slow replies from an internal endpoint by retrying hard enough to multiply traffic roughly tenfold, pushing the Copilot Token Service from 7-9K requests per second to 70-100K. That load landed on the service during recovery, so Copilot did not clear until 21:02 UTC while most other services were back around 16:36 UTC. GitHub names one other factor that impeded recovery, scraping attacks on its codeload endpoints, without quantifying it.
What is an Istio sidecar and why does it matter here?
It is a proxy deployed alongside each service that handles that service's network traffic. GitHub says the sidecar reached its concurrency limit while the autoscaling policy watched host service capacity rather than sidecar limits, so the system had no signal that the constrained component was full. The scaling rule was pointed at a metric that could not observe the failure it existed to prevent.
How much of this is independently confirmed?
None of it. Both the incident thread of August 18 and the company blog post of August 20 are GitHub's own account of its own failure, with the usual incentive to describe causes as narrow and already addressed. The technical detail here comes from the incident thread; the company blog stays high-level and does not name Istio, HAProxy, VS Code or the autoscaling misconfiguration.
Sources
- GitHub, incident thread for the August 17, 2026 GitHub.com incident — the UTC window, the error rates, the Istio and HAProxy chain, the VS Code retry bug and the 10x figure
- Vlad Fedorov, "The August 17 outage and the work ahead," GitHub Blog (August 20, 2026) — the 7h 47m duration, the Central US scaling failure and the client-side retry loop
Chandni Melwani
Chandni Melwani is the founder and editor of New in AI, covering AI agents, M&A, and enterprise adoption. She holds a Master's in Management of Artificial Intelligence from Queen's University and brings a practitioner's perspective from her work in Data and AI leadership.
Follow ↗General Briefing
Get the five-beat briefing before the market opens.
One email. Frontier labs, AI at work, e-commerce, and the capital crossing borders — decoded daily.
No spam. Unsubscribe anytime.
More from General
Legal
Amodei is named again, and has already moved to dismiss
Dario Amodei and Benjamin Mann are named as individual defendants in a copyright suit filed August 28 by Sony Music Publishing and Warner Chappell Music. It is not the first filing to name them, and Amodei is already contesting the personal claim in an earlier case.
Chandni Melwani · Aug 29, 2026
Legal
Judge rules Pentagon's Anthropic risk label unconstitutional
To defend banning Anthropic across the federal government, the Department of War produced four pages. It abandoned its backdoor-access theory in court, conceded Claude is no riskier than any other black box model, and rested the ban on one remaining factor it called trust.
Chandni Melwani · US · Aug 28, 2026
Money
Stripe is buying the meter on AI spending
OpenRouter sits between developers and 400-plus models, so it already knows which ones get picked and what they cost. That ledger now belongs to a payments company.
Chandni Melwani · Aug 24, 2026