During GitHub’s August 17 outage, a latent retry bug amplified traffic by approximately 10×. The interesting part isn’t that retries failed. It’s that the system kept retrying after retries had become part of the problem.
On August 17, GitHub experienced an outage lasting 7 hours and 47 minutes.
GitHub.com, authentication, Actions, APIs, pull requests, issues and Copilot were all affected.
The initial problem was capacity. Traffic reached a new peak, and a critical infrastructure component failed to scale with it.
But what happened during recovery is more interesting.
Some Copilot services continued returning errors.
Clients did what software is often designed to do when something fails:
They retried.
According to GitHub’s incident report, delayed responses triggered a latent retry bug in VS Code that amplified traffic by approximately 10× and delayed recovery of the Copilot Token Service.
The system was already struggling.
The recovery mechanism created more load.
That exposes a simple distinction:
A retry is an action. Recovery is an outcome.
The problem isn’t retries
Retries are essential in distributed systems.
The problem is deciding when a retry is still helping.
GitHub’s response is telling. The company says it is introducing:
- consistent retry limits
- retry budgets
- variable timeouts
The goal is to prevent retry storms and cascading load.
Those are important safeguards.
But they point to a deeper question.
Not:
How many times should we retry?
But:
Should we retry this failure at all?
A failed request contains more information than simply “it didn’t work.”
The response may tell you to slow down. The destination may already be degraded. Identical attempts may be failing repeatedly. The failure may be transient — or structural.
At some point, another retry can stop being part of the recovery strategy and start becoming part of the incident.
We wrote about the broader problem in Your Retry Logic Is Lying to You.
Retry logic needs judgment
Traditional retry logic is mostly about timing:
fail → wait → retry
More resilient failure handling needs to make a decision:
classify the failure → understand destination state → choose the next action → escalate when needed
Sometimes that means retry.
Sometimes backoff.
Sometimes respecting Retry-After.
Sometimes pausing an unhealthy destination, changing the request or involving a human.
And sometimes the correct action is:
do nothing. Yet.
From retry logic to Failure Intelligence
That decision layer is what we mean by Failure Intelligence.
It uses signals such as response codes, headers, previous attempts and destination health to decide what should happen next.
That decision layer is what Queuey is built for.
Because better reliability isn't necessarily about retrying more successfully.
Sometimes it's about knowing not to retry at all.
What GitHub’s incident really shows
GitHub’s incident is a useful reminder that retry behavior is part of system design — not just a fallback.
At GitHub’s scale, a retry mechanism still amplified traffic by roughly 10× during recovery.
The question isn't whether your system can retry.
It's whether it knows when it should.