On August 17, at 13:28 UTC, GitHub began to fail. By the time it fully recovered at 21:15 UTC — 7 hours and 47 minutes later — the company had published a postmortem that reads less like an incident report and more like a field note from the future.
The root cause, as GitHub’s own blog describes it, was network saturation on load balancers in its Central US facility, triggered when an Istio sidecar hit its concurrency limit. That’s the kind of sentence that makes non-engineers’ eyes glaze over. But buried in the postmortem is a detail that should make everyone sit up: during recovery, errors in Copilot services “triggered a client-side retry loop that increased traffic.” GitHub had to mitigate that behavior before it could safely restore traffic.
Read that again. The outage wasn’t prolonged by a bad deploy or a careless engineer. It was prolonged by software doing exactly what it was told to do. Copilot clients, encountering errors, retried. And retried. And retried. At machine speed, with machine patience — which is to say, none at all.
The Users Are No Longer Human
For decades, we’ve built infrastructure on a quiet assumption: that users are human. Humans are patient. They get bored. They go to lunch. They check their phones. When a service is down, a human developer might hit refresh a few times, then wander off to get coffee. That natural human impatience — the tendency to give up — is a load-shedding mechanism. It’s built into the system, and we’ve never had to design for its absence.
AI agents don’t get bored. They don’t go to lunch. They retry at millisecond intervals until the service responds or the heat death of the universe, whichever comes first. Copilot, with its 2.9 billion monthly commits, is the leading edge of a shift that will eventually hit every platform: the user base is no longer human.
A platform engineer at a mid-sized fintech, watching the incident unfold from a war-room Slack channel, put it this way: “We kept telling ourselves it would recover any minute. Then someone pointed out our own retry logic was doing the same thing Copilot was doing — hammering the API every 200 milliseconds. We were part of the storm.”
That’s the uncomfortable part. It wasn’t just Copilot. It was every CI pipeline, every IDE plugin, every automated tool that treats a 503 as an invitation to try harder.
The Demand Side of the Outage
The Register’s coverage noted that GitHub’s postmortem points to “capacity failure at unprecedented traffic” — not a careless deploy. GitHub is spending, in its own words, “cores, petabytes, and Azure footprint to catch up.” The AI coding boom is generating load no human could produce. This isn’t a GitHub problem. It’s an industry problem.
Every platform that serves AI agents — not just code hosts, but APIs, databases, payment processors, anything with a programmatic interface — is going to face the retry storm. The question is whether they’ll design for it before it happens or after.
GitHub’s fix is sensible: consistent retry limits, retry budgets, variable timeouts across service-to-service interactions. But that’s a technical patch on an architectural problem. Retry budgets assume you can distinguish between a legitimate retry and a storm. When your users are machines, that distinction gets blurry.
Who’s Responsible When the Machines Melt the Service?
There’s a governance question here that nobody wants to answer. When an AI agent’s retry loop takes down a service, who’s responsible? The agent’s operator? The platform? The model provider? The answer, right now, is: nobody. The agent retries, the service melts, and everyone writes a postmortem.
That’s not sustainable. As AI agents become a larger share of platform traffic, the industry is going to need norms — if not rules — about how machines are allowed to behave when a service is degraded. Exponential backoff isn’t just good manners; it’s going to become a compliance requirement. The alternative is a world where every outage is amplified by a million well-intentioned robots, and every postmortem reads like GitHub’s: a story about how the recovery was harder than the failure.
The August 17 outage wasn’t a catastrophe. Most services recovered within hours. But it was a preview. The next time a major platform goes down, the retry storm won’t be a footnote in the postmortem. It’ll be the headline.
Sources
- GitHub Is Down: The August 17, 2026 Outage in Detail
- GitHub outage on August 17, 2026… - Muhammad Rabiu Ismail
- Turns out “try again” can make the outage worse. Much worse …
- The August 17 outage, and the work ahead - The GitHub Blog
- GitHub blames 8-hour outage on autoscaling fail and VS Code retry storm
- GitHub Outage Aug 17: 7h47m, 2.9B Commits, RCA