Monday afternoon, 13:28 UTC, and roughly one request in five to github.com came back an error. That ran for 7 hours and 47 minutes, and the incident report GitHub posted afterwards names a cause with no bad deploy in it anywhere: an Istio sidecar pod hit its concurrency limit and never scaled, because the scaling policy was watching the host service and not the sidecar. Then it spread. Four HAProxy nodes exhausted their flow limits, the gateway auth path went down with them, and a dormant retry bug in VS Code multiplied Copilot token traffic roughly tenfold on the way back up. We read both writeups GitHub published, which don't say quite the same thing, and pulled out the part that applies to anyone running a mesh.
The short answer
GitHub.com was degraded for 7 hours and 47 minutes on 17 August 2026. No code change, no config change. An Istio sidecar pod in the Central US datacenter hit its concurrency limit and failed to auto scale, because the scaling policy watched the host service and not the sidecar. Load balancers saturated, four HAProxy nodes exhausted their flow limits, and the gateway auth path took SAML and OIDC sign-in down with it. Pausing HAProxy on those nodes at once brought broad recovery. Copilot lagged another three hours because a latent VS Code retry bug pushed the token service from 7 to 9K RPS up to 70 to 100K.
The chain, in order
Two documents came out of this and they’re pitched at different readers. The CTO’s blog post on 20 August is the corporate one, and it stops at “a critical infrastructure component in our Central US data center failed to scale with it.” The status page resolution note is where the engineering actually lives, and it’s unusually candid.
Here’s what it says. Traffic reached a new peak. An Istio sidecar pod reached its concurrency limits and failed to auto scale correctly, because of a misconfigured policy that watched host service but not sidecar limits. One failure cascaded to more, and eventually four HAProxy nodes exhausted their flow limits, degrading the gateway auth path. That’s the whole outage in three sentences, and the interesting word is sidecar.
Because that’s the bit that generalises. If you run a service mesh, your HPA is almost certainly scaling on the application container. CPU, memory, maybe a custom queue-depth metric from the app itself. The proxy that every one of those requests has to pass through on the way in and out has its own concurrency ceiling, and it is not the same number. GitHub’s policy was watching one and the traffic was killing the other. Nothing in the dashboards said “scale me” because the thing being asked to scale wasn’t the thing being measured.
Then the failure modes stack. Auth is the nastiest one to lose, and GitHub lost it broadly: SAML and OIDC sign-in, SCIM, Team Sync. Also, in a detail almost nobody picked up, Actions workflows in GHEC with Data Residency that depend on public workflow step definitions hosted on github.com. Your sovereign-region CI has a dependency on the public site. Worth knowing before your next audit.
The recovery reads like a bad night. Some failing traffic got moved from Central US to Northern Virginia, where it was served fine, and promptly started a retry storm of its own. GitHub fixed that by shipping a PR to trim gateway retry logic and then blocking inbound Copilot token requests at the load balancers with a flat 403, ramping traffic back up per site so callers could actually succeed. Deliberately serving errors to stop serving errors. It works, but you have to be willing to do it.
The Copilot tail is its own lesson. A failed token operation could generate many extra requests and enter a retry loop, so the token service went from a normal 7 to 9K RPS to 70 to 100K. Roughly ten times, from clients, during recovery. GitHub names the culprit plainly: a latent retry bug in VS Code, triggered by delayed replies to a single internal endpoint. One slow endpoint, one editor shipped to millions of desktops, and your recovery window stretches by three hours. There were also scraping attacks on codeload endpoints muddying the picture while all this ran.
The number in the blog post
The CTO post is thinner on mechanism but it carries the stat that actually explains the year. Since April, monthly commits on GitHub have grown from 1.4 billion to 2.9 billion. Doubled. In four months.
Fedorov is careful about it: “That growth explains the pressure on our systems, but it does not excuse these outages.” Fair. But it reframes what these incidents are. This wasn’t a platform slowly outgrowing its capacity plan. It’s a platform whose load curve went vertical, largely because agents now write and push code at machine pace, running into limits that were provisioned for humans typing. GitHub says it has added more than 3 million CPU cores and 120 petabytes of high-speed storage, and installed as much hardware as available power allowed in existing datacenters. Azure now carries roughly 58 percent of platform load and half of all Git operations, up from 12 percent of platform load in May.
That’s a genuinely enormous migration to be running while your commit volume doubles. I’d argue the surprise isn’t that August had two bad days. It’s that the number is 58 and not 20.
Three things to go check this afternoon
The first one costs you ten minutes. Pull up any HPA in front of a meshed workload and ask what metric it scales on. If the answer is the app container’s CPU, you have GitHub’s bug. Istio’s sidecar has its own concurrency and connection limits, and they need to be in the scaling signal or at least in an alert. GitHub’s own follow-up list starts with exactly this, plus an audit of Istio request, concurrency and scaling limits across affected services.
Second, retries. Both of GitHub’s remediations that touch code are about retry discipline: consistent retry limits, retry budgets, variable timeouts across service-to-service calls. A retry storm doesn’t need a bug to hurt you, it just needs enough clients being optimistic at the same moment. And check the clients you ship, not only the servers you run, because the VS Code amplification came from software GitHub wrote and users installed.
Third, the boring one nobody does: know what breaks for you when github.com is 20 percent errors for eight hours. Not the drama, the actual list. Which pipelines block, which deploys can’t fetch, whether your runners can still authenticate. GitHub’s own numbers say the platform is under structural strain while a huge infrastructure migration runs underneath it, and 6 and 17 August were nine days apart. Plan like there’ll be a third.
If you’re checking whether an endpoint is genuinely back or just returning a polite error page, our HTTP headers checker shows you the raw status and response headers. And if the Actions side of this is your problem, the Bun 1.4 release quietly changed how the on: key in a workflow file parses, which is a different way to lose a morning to CI.
Sources
GitHub’s public incident record for this outage sits in two places: the resolution note on the GitHub Status history, which carries the technical detail on the Istio sidecar, the HAProxy nodes and the Copilot Token Service traffic figures, and the CTO post “The August 17 outage, and the work ahead” by Vlad Fedorov, published 20 August 2026, which is the source for the commit growth, the added capacity and the Azure share. Both were read on 23 August 2026. The 6 August Actions incident is recorded separately in the same status history.
Frequently asked questions
How long was GitHub down on 17 August 2026?
7 hours and 47 minutes, from 13:28 to 21:15 UTC. At peak, web and API error rates ran around 20 percent, while archive and raw repository content downloads hit roughly 50 percent. Most services came back as the Central US datacenter recovered at about 16:36 UTC, Actions stayed degraded until roughly 18:03 UTC, and the Copilot Token Service was the last to clear at 21:02.
What caused the GitHub outage?
GitHub's incident report puts the immediate cause as network saturation on load balancers in Central US after traffic hit a new peak. The origin was an Istio sidecar pod reaching its concurrency limits and failing to auto scale, because a misconfigured policy watched the host service rather than the sidecar's own limits. That cascaded until four HAProxy nodes exhausted their flow limits, which degraded the gateway auth path.
Was the outage caused by a bad deployment?
No. GitHub's CTO Vlad Fedorov wrote that neither the 6 August nor the 17 August incident came from a code or configuration change, and that both were capacity failures at their core. The company says it failed to scale critical components before demand exceeded their capacity.
What did GitHub do to stop it?
Pausing HAProxy on the affected nodes simultaneously produced immediate broad recovery. Before that, some failing traffic was shifted from Central US to Northern Virginia, which set off a second retry storm there. That one was handled by shipping a PR to reduce gateway retry logic and by blocking inbound Copilot Token Service token requests at the load balancers with a 403, then ramping traffic back per site.
What is GitHub changing so it does not happen again?
Five follow-ups are listed: correcting autoscaling policies to account for service-mesh sidecar concurrency and capacity, auditing Istio request, concurrency and scaling limits across affected services, reviewing retry limits and backoff behaviour across gateways and clients, addressing the VS Code retry behaviour that amplified Copilot token traffic, and improving load-balancer capacity monitoring plus regional failover safeguards. None carries a published completion date.
