SAN FRANCISCO, 24 AUG 2026 — GitHub has published its account of the 17 August incident we reported last week, and two things in it were not visible from the outside.
The incident ran 13:28 to 21:15 UTC, seven hours and forty-seven minutes, not the roughly three hours most of us experienced. And part of what kept it going was a retry bug in a code editor.
The recovery was staged, which is why the duration was underreported
Most services came back at 16:36 UTC when the Central US datacentre recovered, which is about three hours in and the point at which the outage stopped being visible to most people.
Actions stayed degraded until roughly 18:03. The Copilot Token Service did not fully recover until 21:02. Anyone who checked GitHub at four in the afternoon UTC, saw the site working and concluded it was over was right about the website and wrong about the platform.
A retry bug turned a capacity problem into a longer one
The immediate cause was network saturation on load balancers in Central US, brought on by a new peak in traffic. That is an ordinary capacity failure and it would have resolved when the datacentre did.
What extended it was downstream. Delayed replies from a single internal endpoint triggered a latent retry bug in Visual Studio Code, which amplified traffic by roughly ten times. The clients trying to recover became the thing preventing recovery, and the Copilot Token Service wore it for another three hours after everything else was healthy.
This is the failure mode every distributed system carries and few teams test for. At low volume, a retry is a correctness feature. At scale, it is a denial-of-service amplifier. The bug was latent, needing a slow endpoint to express itself — precisely the condition an outage creates.
The blast radius reached further than code hosting
The published scope includes services that do not look like GitHub from a user's perspective.
SAML, OIDC, SCIM and Team Sync were all affected. An organisation federating identity through GitHub had an authentication dependency it might not have drawn on any diagram.
Actions workflows in GitHub Enterprise Cloud with Data Residency were also hit, because they depend on public workflow step definitions hosted on GitHub.com. Anyone who bought data residency believing it provided isolation should note what happened here. The data stayed in region, but the workflow definitions did not.
It happened overnight in this region
13:28 to 21:15 UTC is 21:28 to 05:15 in Singapore, Kuala Lumpur and Manila. The entire incident, from saturation to full recovery, fell inside the hours when almost nobody in ASEAN was at a desk.
That produces a specific shape of Monday morning. Overnight scheduled jobs failed, the status page was green by the time anyone read it, and the failures looked like flaky tests or a bad merge rather than an upstream outage. A team without alerting tied to the provider's status would have spent the morning debugging its own pipeline for a fault that had already been fixed on another continent.
Before diagnosing your own pipeline, check your failed runs against the provider's incident timeline. It is a two-minute check that can save a morning — something that only becomes obvious after you have lost one.
What data residency did and did not cover
The Enterprise Cloud detail is worth drawing out for anyone in this region who bought data residency for regulatory reasons.
Residency governs where your repository data is stored and processed. It does not make your builds independent of GitHub.com, because a workflow that references a public action fetches that step definition from the public service at run time. The regulated data stayed where it was contracted to stay; the build that operates on it stopped.
For an organisation whose residency commitment exists to satisfy a supervisor — a bank under a critical-information-infrastructure code, say — that distinction is worth understanding before an auditor asks. Residency is a data-location control, not an availability control, and the two get conflated in procurement more often than in engineering.
What this does to the concentration argument
Our earlier report made the point that continuous integration broke in organisations that had not registered they depended on GitHub being available. The post-incident detail sharpens it rather than softening it.
A three-hour outage is an inconvenience most teams absorb. An eight-hour one that degrades Actions for five hours and Copilot for seven is a working day, and the recovery profile means a team could have restarted its pipelines twice and failed twice before the platform was actually ready.
The practical lesson is in how you decide an incident is over. A green status page is not the same as a healthy service, and in this case, the two were four hours apart.
The mitigation is boring and worth doing
Nothing here is exotic, and the fixes are the ones that get deferred because they have no visible payoff until a day like this.
Mirror the actions you depend on rather than pulling step definitions from a public repository at run time. Pin them by commit rather than by tag. Cache archives and container images somewhere you control, because archive downloads were the worst-affected surface at around 50 per cent failure. And decide in advance which of your pipelines may fail open and which must block.
The retry bug is not something a customer can fix, and it is a reminder that your dependency is not only the provider but every client library between you and it.
Two outages, five days apart
To be clear, as some roundups have conflated them: this is the same 17 August incident, not a new one. The report just arrived later.
What has changed since is the surrounding picture rather than GitHub's reliability. Automation billed by consumption keeps consuming while the pipeline underneath it fails, and code-review workflows have drawn on Actions minutes since 1 June. An outage that leaves Actions degraded for five hours is now also a billing event for teams that retry aggressively into it.
View author profile → · Editorial policy
