A Copilot retry storm stretched a GitHub capacity blip into a near 8-hour outage

What happened

On August 17, 2026, GitHub served errors to users for nearly eight hours straight. According to a post on dev.to analyzing the incident, the degradation ran from 13:28 to 21:15 UTC — 7 hours and 47 minutes — and affected Git operations, Actions, Issues, pull requests and Copilot. Around 20 percent of web and API requests failed, and failure rates for archive and raw-content downloads reached roughly 50 percent.

The trigger was a proxy nobody was autoscaling

The dev.to write-up traces the initial fault to an Istio sidecar proxy that ran into its concurrency limit. The bigger problem was the blind spot around it: GitHub's autoscaling reportedly watched the metrics of the host application rather than the sidecar's saturation. From the autoscaler's perspective everything looked healthy, so no additional instances were provisioned. Excess traffic then spilled over, pushed four HAProxy nodes past their capacity limits and degraded the gateway tier.

By itself, the author argues, this was a fixable capacity problem. What stretched it into a saga happened on the client side.

A retry loop aimed at a recovering service

Per the dev.to post, a hidden bug in the VS Code Copilot extension caused clients to repeatedly request fresh authentication tokens from the Copilot Token Service. When the service returned backend errors, the clients did what they considered the resilient thing: they tried again, immediately, over and over.

The numbers are stark. The Token Service normally handles 7,000 to 9,000 requests per second. During the incident it received 70,000 to 100,000 RPS — eight to fourteen times its usual load, all aimed at infrastructure that was simultaneously trying to recover.

As quoted in the post, GitHub CTO Vlad Fedorov described the dynamic plainly: backend errors "triggered a client-side retry loop that increased traffic during recovery."

Why naive retries make outages worse

The author's central argument is that retries are routinely treated as free resilience when they are nothing of the sort. An unbounded, immediate retry loop amounts to an accidental denial-of-service attack, with every helpfully retrying client acting like another node in a botnet its own operator funded. Three missing properties turn a retry into a stampede:

• No budget: clients retry without limit, so the added load has no ceiling.
• No backoff: retries fire instantly, giving a struggling service no breathing room.
• No jitter: everyone retries on the same clock, so requests arrive in synchronized waves.

Recovery requires slack, the post notes, and naive retries consume whatever slack exists the moment failures begin. Even exponential backoff without jitter can recreate a thundering herd, because every client waits the same interval and fires at the same instant.

The fixes are unglamorous but proven

The post prescribes two standard remedies. A retry budget caps retries as a fraction of overall traffic — for instance, retries must stay under 10 percent of requests. Once the cap is reached, clients fail fast rather than trying again. In GitHub's case, that single rule would have bounded the Token Service surge instead of letting it climb to 14 times normal volume.

Backoff with jitter then handles timing: delays spread retries out so a damaged service can catch its breath, and randomized wait times stop clients from synchronizing into waves.

Why it matters

This incident is a case study in resilience being a shared responsibility between clients and servers. A buggy extension in a widely installed editor effectively mounted a distributed attack on GitHub's own authentication infrastructure — not by design, but through the omission of safeguards that distributed-systems literature has recommended for decades.

Two audiences should take note. Platform operators need to autoscale on the metrics of every layer that can saturate, including sidecar proxies; otherwise the capacity system reports "normal" while the service melts. And anyone writing client code should audit their retry logic. The dev.to author's verdict is blunt: if a retry can happen immediately, infinitely and for free, that is not a resilience pattern — it is a bug waiting for an outage.