“The best-laid plans of mice and men often go awry.” - Robert Burns
On August 17, GitHub went down for 7 hours and 47 minutes. When they tried to bring it back up, part of the recovery effort made things worse, on purpose, without anyone intending it.
THE SIGNAL
GitHub’s CTO published a public account of the outage on August 20.
A critical infrastructure component in the company’s Central US data center failed to scale when traffic hit a new peak.
The resulting capacity pressure spread through GitHub’s systems and caused authentication failures across github.com, Actions, APIs, pull requests, issues, and Copilot.
It was the company’s second significant incident that month.
Both incidents were capacity failures, not code or configuration changes. Monthly commits had grown from 1.4 billion to 2.9 billion since April, and the infrastructure had not caught up.
Most services recovered within hours.
Copilot did not.
Errors in that service triggered a client-side retry loop that increased traffic during the recovery itself, and engineers had to contain that new surge before they could safely restore the rest of the platform.
THE FAILURE POINT
The system ran out of capacity once.
Then the mechanism built to recover from that failure added load back onto a system that was still trying to stand up, doubling the same incident into two.
SIGNAL WITHIN THE SIGNAL
Every layer here executed a locally correct instruction.
The Copilot client was built to retry a failed request rather than give up on the user.
That’s good design in isolation.
Nobody scoped that retry logic to ask what happens when thousands of clients retry at once, into a system that’s already recovering from the exact overload the retries are about to recreate.
The signal that mattered, aggregate retry volume during active recovery, never had an owner. It lived in the gap between “protect this session” and “protect this platform.”
That gap is where Signal Compression always hides: a true instruction, followed correctly, at a scope too narrow to see the whole system.
Worth checking where your own team sits on that same gap before assuming it's someone else's problem.
Score your gap →
BEHAVIOR UNDER PRESSURE
Under a growth curve that doubled commit volume in four months, engineering teams optimized for the metric in front of them: uptime for their own service, recovery speed for their own component.
Nobody owned the interaction between “my service is recovering” and “my recovery behavior is now everyone else’s incoming load.” That ownership gap does not show up on a dashboard.
It shows up in a root cause analysis, after the second outage of the month.
SYSTEM DRIVER - MOS
The structural fix is not another layer of per-service reliability targets.
It is a shared recovery protocol: consistent retry limits, retry budgets, and variable timeouts enforced across every service-to-service interaction, reviewed as one system rather than approved service by service.
GitHub named this exact fix in its own postmortem. The question worth asking is why it took two outages in one month to make it a standard instead of a lesson.
LEADER DRIVER - INTERNAL OPERATING SYSTEM (IOS) - REGULATE
The read here is an inference, not a confirmed account of any one engineer’s thinking.
But the pattern suggests teams under sustained growth pressure are incentivized to ship resilience features, like retries, that make their own service look more robust, without a mandate to model how that resilience behaves at platform scale.
Asking what this does to everyone else during a bad day is not anyone’s job unless someone assigns it.
IF YOU DO ONE THING TODAY
If your business depends on a vendor’s platform: pull their last postmortem. If “capacity” shows up as the cause twice in one quarter, that’s a signal.
Ask your vendor relationship owner one question today: is their recovery process reviewed as a whole system, or just service by service?
Get a real answer before your next contract renewal.
FINAL SIGNAL
Every part can work perfectly, and the whole thing can still fail. Twice. In the same incident.
Why? Because “correct” for each piece doesn’t add up to “correct” for the system, unless someone is responsible for making sure it does.
CTA
Find out where your gap is before it costs you. Score your own gap here, takes about three minutes.
mosei.org/gap-diagnostic.html
SOURCES
GitHub Blog, “The August 17 outage, and the work ahead,” August 20, 2026.