GitHub's 8-hour outage wasn't a capacity problem. It was an unscored queue.

At 13:28 UTC on August 17, one Istio sidecar in GitHub's Central US datacenter hit its concurrency ceiling. The autoscaling policy watching over it was checking the health of the host service, not the sidecar itself, so nothing scaled up to absorb the load. Web and API error rates climbed to roughly 20%; archive and raw-content downloads hit 50%. It was a real problem, but a bounded one — the kind of thing a good incident team clears in under an hour.

GitHub's team did clear it. Most services had recovered by 16:36 UTC, three hours after it started. If the story ended there, this would be a Tuesday. Instead, the outage ran for 7 hours and 47 minutes, because something else was already happening underneath it: a latent retry bug in VS Code had turned a slow endpoint into a load generator running on millions of laptops. Copilot Token Service traffic, normally 7,000–9,000 requests per second, spiked to 70,000–100,000. The retry storm kept hammering the recovered infrastructure for five more hours after the original cause was fixed.

The queue couldn't tell a retry from a request

Here's the detail worth sitting with: GitHub's systems, under load, had no way to distinguish a legitimate first-time request from a client blindly re-sending the same failed call for the fourth time. Both looked identical to the load balancer. Both competed for the same finite capacity, on equal footing, with no mechanism to say "this one can wait" or "this one doesn't count." So a five-alarm queue of noise got exactly as much priority as everything else trying to get through — and starved the real work.

GitHub's own remediation plan says the quiet part out loud: retry limits, retry budgets, variable timeouts across service-to-service calls, and load balancers configured to reject excess Copilot Token Service traffic outright with an HTTP 403 rather than let it queue. In plain terms — build a system that can tell what to drop.

This is a triage failure, not a capacity failure

Swap "requests" for "incoming project requests" and the pattern is familiar to anyone who's run an intake process without one. A queue that treats every submission — the well-scoped ask from a paying customer, the fourth resubmission of a request someone already declined, the "just checking in" from a stakeholder with no real stake — as equally deserving of attention doesn't fail because there isn't enough capacity. It fails because nothing in the system can tell the difference between signal and noise fast enough to shed the noise.

Most teams find this out the expensive way: not during a quiet month, but during exactly the moment demand spikes — a reorg, a product launch, budget season — when the volume of "urgent" asks triples and there's no scored, standing rule for what actually gets to jump the queue. Capacity that would have been fine under normal load buckles, and it looks like a resourcing problem. It's a triage problem. The fix isn't more capacity. It's a queue that can reject or defer the low-value stuff before it ever reaches the people doing real work.

That's the boring, unglamorous infrastructure question sitting underneath both an Istio sidecar and a request intake form: when the queue fills up, does anything in the system know what to say no to — or does everything just wait its turn, undifferentiated, until the whole thing falls over? Admisio scores incoming project requests as they land, so low-value and duplicate asks never get to compete for the same attention as the ones that matter.

Sources: The GitHub Blog — "The August 17 outage, and the work ahead" (Aug 19, 2026); The Register — "GitHub blames 8-hour outage on autoscaling fail and VS Code retry storm" (Aug 19, 2026).