GitHub's worst outage of 2026 wasn't caused by a failed server, but by its own AI assistant retrying requests too aggressively during recovery. On August 17, a capacity issue in GitHub's Central US data center triggered a chain reaction: when services started returning errors, GitHub Copilot's client-side retry loop kept hammering the struggling backend, converting a partial outage into a seven-hour, 47-minute platform failure that affected authentication, pull requests, Actions, and the API.

The incident reveals a critical gap in how AI coding agents are built. While traditional infrastructure has spent years perfecting retry controls, most AI agent systems ship with only basic per-request retry logic and no fleet-wide safeguards. That means your coding agents, CI/CD jobs, and LLM gateways are all capable of amplifying failures in ways your organization probably hasn't accounted for.

What Actually Happened on August 17?

GitHub's investigation traced the failure to a monitoring gap, not a lack of hardware. An Istio sidecar proxy in the Central US data center hit its concurrency limit and failed to autoscale because the scaling policy was watching the host service instead of the sidecar itself. Four HAProxy nodes then exhausted their flow limits, degrading the authentication path that everything on GitHub depends on.

The scale of GitHub's growth made the problem worse. Monthly commits grew from 1.4 billion in April 2026 to 2.9 billion by August. The platform now processes roughly 130 million merged pull requests and 24 million new repositories monthly, with Actions runs climbing past 115 million. Azure now serves about 58 percent of platform load, up from 12 percent in May. Traffic doubled in four months, and the autoscaling infrastructure didn't keep pace.

But the most revealing number came after the initial failure. Traffic to the Copilot Token Service spiked from a normal 7,000 to 9,000 requests per second to 70,000 to 100,000 requests per second, roughly a tenfold amplification. That surge wasn't from new users; it was from Copilot's client retrying authentication token requests without pausing when the token service answered slowly or failed. GitHub had to block Copilot's traffic at the load balancers with a 403 error just to recover the platform.

Why Do Retry Loops Cause Cascading Failures?

A retry storm is an old failure mode with a new client. When a service starts returning errors and its clients respond by sending more requests, a partial brownout becomes a total outage. Google's Site Reliability Engineering handbook, published over a decade ago, prescribes two distinct controls that most teams conflate into one.

The first is a per-request retry budget: if a request has already failed three times, let the failure bubble up to the caller. Almost every HTTP library exposes this knob, and most teams have it. The second is a per-client retry budget, and almost nobody has it: each client keeps track of the ratio of requests that correspond to retries, and a request will only be retried as long as that ratio stays below 10 percent.

The difference is not academic. Google's own arithmetic shows that without the per-client cap, worst-case request growth at a failing datacenter reaches "somewhere just below 3X." With the per-client cap, it stays at "just 1.1x in the general case." Three times the load arriving at a component that just failed to scale is precisely the shape of August 17.

How to Implement Retry Budgets for AI Agents

• Per-Request Limits: Cap individual request retries at three attempts maximum. Most LLM SDKs ship with this by default, but verify your configuration explicitly sets the retry count rather than relying on defaults.
• Per-Client Budgets: Track the ratio of retries to total requests for each agent or client. Implement a circuit breaker that stops retrying once retries exceed 10 percent of total traffic from that client, preventing amplification during failures.
• Stacking Prevention: Ensure that a failed request is retried by exactly one layer, the one immediately above the failure. If your agent layer retries, your tool layer, your HTTP client, your gateway, and your CI runner all retry independently, you get a combinatorial explosion of requests.
• Exponential Backoff with Jitter: Add randomized delays between retries so that multiple agents don't retry at the same moment. This prevents synchronized retry storms that can overwhelm a recovering service.

The infrastructure world has been converging on the per-client version for years. Envoy, a widely used service mesh, implements retry budgets as a circuit-breaker threshold with a budget percent defaulting to 20 percent of active and pending requests. Kubernetes' Gateway API, currently experimental, proposes the same thing as a first-class policy because "too many client-side retries can also exacerbate consistent failures and slow down recovery, quickly overwhelming a failing system and leading to cascading failures such as retry storms".

The control exists. It has existed for years. It sits in your service mesh, and it does not sit in your agent harness.

What Are AI Agents Currently Doing?

Every mainstream LLM SDK ships a per-request retry budget on by default and no per-client budget at all. The OpenAI Python SDK automatically retries certain errors, including connection errors, 408 request timeouts, 409 conflicts, 429 rate limits, and any 500-level server errors, up to two times by default with exponential backoff. The default request timeout is ten minutes.

Anthropic's documented behavior follows the same pattern: the official SDKs automatically retry transient failures such as connection errors, rate limits, and 5xx server errors with exponential backoff, twice by default. Those are reasonable defaults for one client. They are not a fleet control. Nothing in either SDK knows what fraction of your organization's traffic is currently retries, and nothing stops a hundred agent sessions from each independently deciding, at the same moment, that the 429 rate-limit error they just received deserves another attempt.

Then stack the layers: the agent loop retries the tool call, the tool retries the HTTP request, the SDK retries the API call, the gateway retries upstream, and the runner retries the whole job. Four layers of three attempts is eighty-one requests for one user action.

What Should Organizations Do Now?

GitHub's postmortem should prompt immediate action on your own agent infrastructure. Start by auditing your LLM SDK configurations and your agent harness to identify where retries are happening. Map the layers: agent, tool, HTTP client, gateway, and runner. For each layer, document the retry budget and backoff strategy.

Then implement per-client retry budgets at the agent layer. This is the control that prevents a hundred agents from amplifying a single failure into a platform outage. If your organization runs coding agents, CI/CD agents, or any LLM-based automation at scale, this is not optional infrastructure; it's a prerequisite for safe deployment.

GitHub's CTO Vlad Fedorov's post-incident write-up was unusually direct about the amplifier: errors in those services "triggered a client-side retry loop that increased traffic during recovery." That statement applies to your own estate. The most sophisticated engineering organization in developer tooling shipped an AI client that, on encountering errors from a struggling backend, hit it harder. Your coding agents, your CI jobs, your MCP servers, and your LLM gateway are all doing the same thing right now, on defaults you did not choose.