Everyone's Editor Tried to Help at Once
An autoscaler watching the wrong container, four exhausted load balancers, and a retry bug that turned every open editor into part of the problem. Plain-English translation of GitHub's own incident report.
GitHub went down on 17 August for seven hours and forty-seven minutes. The thing that broke was fixed in about three. The other five hours were millions of code editors, all politely asking again, forever, because nobody had taught them to wait.
Prefer it read to you? Zara does voices now (14 min).
Zara is a character and this voice is synthesized. Mathieu Kessler, the human behind Talk Nerdy to Me, writes and fact-checks every word.
Monday afternoon, and the button does nothing
Here is the moment. It is 13:28 UTC on a Monday, you are halfway through something, and the page does not load.
You press the button again, because that is what everybody does. Nothing. You open a new tab to check whether it is you or them, and while you are doing that, so are several million other people, and so, quietly, is the editor sitting open on your other screen.
That last one is the story.
GitHub was broken on 17 August 2026 for seven hours and forty-seven minutes. The thing that actually broke got fixed in about three. The rest of it, the part that took the afternoon and most of the evening, was software trying to help.
I read the incident report so you do not have to. It is unusually good, in the sense that it contains real numbers and does not hide behind the passive voice as much as these documents usually do. It is also, if you read it the way I read things, a document about something other than what it says it is about.
Nerd to English
Four words you need, and then we can go.
A load balancer is the doorman. Traffic arrives, the doorman decides which of the identical rooms behind it you go into, so that no single room fills up. When people say a site went down, they very often mean the doorman fell over rather than the building.
A sidecar is a small helper program that runs attached to your actual program, one per copy, handling the boring network parts so your program does not have to. It rides along. Hence the name. The important bit: it is a separate thing from the program it is attached to, with its own limits, and you can watch one without watching the other.
RPS is requests per second. How many times a second something is being asked to do its job.
Backoff is the one that matters, and I am going to give it a section of its own later, because it is the word this entire outage turns on and I did not see a single article define it.
What broke, in one paragraph
Traffic hit a new peak. A sidecar in GitHub's Central US datacenter reached its concurrency limit, which means it hit the maximum number of things it can handle at once. Normally that triggers more capacity automatically. It did not, and here is the sentence, in GitHub's words:
"[It failed] to auto scale correctly because of a misconfigured policy that watched host service but not sidecar limits."
Read that again, because it is the whole first act. The thing that decides whether to add capacity was watching the main program. The main program was fine. The main program was fine in the way that you are fine while the person carrying all your luggage is not. Nobody was watching the helper, so nothing scaled, and the doorman got buried.
Then it spread. "One failure cascaded to more and eventually four HAProxy nodes exhausted their flow limits," which took down the path everything else uses to check who you are. Once the check-who-you-are service is slow, every service that depends on it is slow, and at GitHub that is essentially all of them. Errors on the website and the API hit about 20 percent. Downloads of raw files and archives hit about 50 percent.
That is a bad afternoon, and it is also, by GitHub's own timeline, mostly over by 16:36 UTC.
The part where everybody helps
Now the second act, which is longer than the first.
When a request fails, well-built software tries again. This is correct and you want it. A single retry rescues an enormous number of momentary blips that you would otherwise see as an error, and you have been quietly saved by one several times today.
The problem is what happens when the thing you are retrying is not having a blip. It is drowning. Every retry is one more thing to drown in. GitHub's report puts it with admirable flatness:
"[The problem] was worsened by optimistic retry logic which overloaded internal load balancers."
Optimistic. That is a lovely word for it. The software assumed the failure was temporary and acted accordingly, which is exactly the assumption that makes it permanent.
And then the specific bit, the bit that turns a bad afternoon into a bad evening. Slow replies from one internal endpoint:
"[...] triggered a latent retry bug in VS Code that amplified traffic by approximately 10x."
Latent means it had been sitting in there the whole time, harmless, waiting for the exact conditions that would make it matter.
So picture the shape of it. Not an attacker. Not a botnet. Millions of ordinary code editors, open on ordinary desks, each one politely asking again, and again, at machine speed, without getting bored, without checking whether anyone else was also asking, and without any of their owners knowing it was happening. The service that hands out Copilot tokens normally handles 7,000 to 9,000 requests a second. It went to somewhere between 70,000 and 100,000.
Everyone's editor tried to help at once. That was the outage.
Backoff, the word nobody defined
Here is the concept the whole thing rests on, and it is genuinely simple.
Backoff means waiting longer between each attempt.
You fail, you wait one second. You fail again, you wait two. Then four, then eight. Add a little randomness so that everybody's clock does not line up and produce a stampede on the same tick, which is a real thing with the excellent name "thundering herd."
Backoff is the difference between a crowd and a queue. Without it, a system that is briefly struggling gets hit by everything it just failed, immediately, on top of everything new, and cannot ever catch up. It is not that the retries are wrong. It is that retrying at full speed forever is a decision, made by whoever wrote that loop, usually years earlier, usually while thinking about something else.
Look at what GitHub committed to afterwards. Five follow-up actions. The third is "reviewing retry limits and backoff behavior across gateways and clients." The fourth is fixing the VS Code behaviour specifically. Two of their five fixes are about how their software fails, not about what failed.
The document is about retries and does not say so
I ran the word counts on GitHub's incident summary. It is 2,990 characters, which is short.
By its own vocabulary, this is not a document about a network fault. It is a document about retries, with a network fault at the beginning. The thing that started it gets a couple of mentions. The thing that sustained it gets nine.
Two of those counts are findings rather than complaints, and I only trust the zeros because I checked that the probe worked first. That is what the non-zero rows above are doing there: an earlier version of this count returned zero for everything, including the words I could see with my own eyes, because the slice boundary did not match. That result got thrown away rather than published.
The word outage appears zero times. The document describes seven hours and forty-seven minutes in which a fifth of all requests failed, and it calls this "elevated errors and latency." Not wrong. Every word of it is accurate. It is simply not the word that anyone who lived through the afternoon would use.
And there is no apology. No "sorry", no "we regret", nothing. That may not bother you at all, and I am not sure it should. I mention it because the absence is consistent: this is a document written for engineers, in engineering vocabulary, about mechanisms, and the person refreshing a broken page is not in it anywhere. There is a lot to like in that. There is also a reason the coverage all reached for the word "outage" and the company did not.
The fix sounds like giving up
The recovery is my favourite part, because it is so unglamorous.
They paused the four struggling doormen at the same time, and this "produced immediate broad recovery." They then shipped a change to make the gateway retry less. And then they had the load balancers answer inbound token requests with a 403, which is the code meaning "no, and stop asking," before slowly letting traffic back in site by site.
They fixed it by refusing to answer. When too much of your traffic is your own software asking again, the cure is to say no clearly enough that the software stops. A polite failure invites a retry. A flat refusal does not.
There is also an honest complication in the report, which I will pass along because leaving it out would make the story tidier than it was: "a number of scraping attacks on codeload endpoints" made recovery harder. So not every extra request that day was innocent. Most of the ones we are talking about were.
What this proves, and what it does not
The autoscaling miss is the root cause and it is a mundane one. A monitoring policy pointed at the wrong object. Not a clever failure, not an exotic one, and I would guess a version of it exists in most large systems right now, undiscovered, because it only shows up under a peak nobody has hit yet.
The retry amplification is the reason it lasted. That is GitHub's own account, and it is the transferable lesson. The first fault was a capacity problem. The next five hours were a design problem, in client software, on other people's machines, which GitHub could not reach and had to route around.
GitHub published real numbers, and that deserves saying. Exact timestamps, exact error rates, exact request rates, a named client bug in their own parent company's editor, and five specific follow-ups. Plenty of companies would have shipped three sentences about "elevated error rates" and moved on. The reason this post can be precise is that their report is.
And it is not evidence about anybody's reliability in general. One incident is one incident. I have no view on whether this is a trend, I did not measure that, and a post-mortem is the wrong document to answer it with.
Why you, a person with a normal life, might care
Because your tools are participants now. The interesting thing about this outage is that a large part of the traffic came from software nobody was actively using at that moment. It was just open. Every app on your machine that syncs, checks, refreshes or polls is making decisions on your behalf all day, and during a wobble those decisions are either part of the recovery or part of the problem.
Because "it will retry automatically" is a promise with a hidden clause. Whenever something tells you it will keep trying, the useful question is: keep trying how? Once? Ten times? Forever, as fast as it can? The answer is usually invisible and it is the difference between resilience and a stampede.
And because the shape recurs everywhere. A queue forms. Everybody responds to the queue in the same reasonable way at the same time. The response makes the queue worse. That is the traffic jam where nobody crashed, the bank run at a solvent bank, the group chat where six people simultaneously type "did anyone else get this?" Backoff is the general answer, and almost nothing that humans build has it switched on by default.
The human part
Somebody wrote that VS Code retry loop. It worked correctly for years. It was, on every ordinary day, the reason a small hiccup never reached you, and it was probably a good piece of code, reviewed by someone sensible, shipped without incident.
And on one Monday in August, under one specific kind of slowness, it became the largest single source of load on the service it was waiting for, and it did that a few million times over, everywhere at once, on behalf of people who were mostly just looking at a spinner and wondering whether to make a coffee.
Nothing malicious. Nothing incompetent. Just a helpful reflex, running at scale, with no instruction to wait.
The outage lasted three hours. The politeness lasted five.
So: somewhere on your machine right now, something is retrying. An app that syncs, a client that reconnects, a thing with a spinner that never quite gives up. Go and look for whether anybody gave it a wait, and if you find a setting, or a support page honest enough to say how many times it tries, send it my way. Those I collect.
Sources
Primary source for every quotation and every number here: GitHub, "[2026-08-17] Incident Thread", Discussion #205164, Incident Summary posted 18 August 2026
https://github.com/orgs/community/discussions/205164
Independent coverage confirming the same figures out of the same report: Simon Sharwood, The Register, "GitHub blames 8-hour outage on autoscaling fail and VS Code retry storm" (19 August 2026)
https://www.theregister.com/saas/2026/08/19/github-blames-8-hour-outage-on-autoscaling-fail-and-vs-code-retry-storm/5289547
More Where This Came From
Plain-language translations of the machinery and the money behind the tech headlines. No hype, no vendor agenda, and a standing habit of saying what the evidence does not cover.
Related Posts
The Internet's Politest File Just Got a Doorman
Since 1994, the web's oldest defense against unwanted robots has been a text file politely asking them to leave. On 21 August, Cloudflare started writing that file for you. And on 15 September, for new ad-funded websites behind Cloudflare, the default answer to "may I train on this?" flips to no.
The Switch That Was Already On
Twitch added a switch that lets you stop Amazon from training generative AI on your channel. The switch arrived already on. And one line in the help article, which nobody quoted, says that whether your chat in someone else's stream gets used is a decision that stranger already made for you.
The Chip That Can Only Think One Thought
AMD bought a company whose pitch is four words long: The Model is The Computer. Not a slogan. They etch the model into the metal, and then you cannot change your mind.