Delivery

Ten hours without CI

GitHub Actions failed for ten hours and forty-two minutes on August 6. Read as an instrument, the outage measured every pipeline that runs through it.

Code, Noted3 min readDelivery

On 6 August 2026, at 15:22 UTC, GitHub opened an incident against Actions. It closed at 02:04 the next morning: ten hours and forty-two minutes in which workflow runs failed to start, failed partway through, or sat in a queue, and webhook delivery was throttled to roughly 15 percent of normal while the backlog drained. Pages, Copilot's code review and coding agents, and Enterprise Importer migrations were dragged in behind it. The promised root cause analysis has not appeared as of this writing; the interim notes blame runners being assigned jobs that were no longer valid, a sentence that will deserve its own essay once the details arrive.

Engineering sheet of a delivery path in plan, merge and hatched queue feeding a violet control plane that fans out to hosted and self-hosted runners, dimensioned at ten hours forty-two minutes

Before drawing conclusions, a definition. CI here means the machinery that turns a merged change into an artifact somebody is willing to deploy. Not the tests, not the culture. The machinery.

That machinery used to be a computer you could walk to. The nightly build ran on a box in the office; Hudson gave the box a web page in 2005, and Jenkins inherited it after the 2011 fork, but the box stayed yours, and its failures were your failures, diagnosable by anyone with a badge. Then in August 2019 GitHub made Actions a free CI/CD service for public repositories, and within a few years it had become the default answer to a question most teams stopped asking. The build room moved into someone else's building.

The detail worth keeping from Thursday's log is that self-hosted runners were on the affected list. Organizations that ran their own runner fleets, on their own hardware, behind their own firewalls, still could not build, because a runner does not decide what it runs. Assignment happens in the control plane, and there is exactly one of those. Owning the compute, it turns out, is not the same as owning the build.

So read the outage as an instrument rather than an accident. For any given organization it measured three things. Whether a deploy path exists that does not pass through CI: not whether policy permits one, but whether an engineer under pressure could exercise it at hour six for a fix that could not wait. How much slack the delivery system carries: ten hours of not merging costs one team nothing and costs a team with a contractual release date rather a lot. And whether anyone had rehearsed, because the difference between an inconvenience and an incident is mostly whether the procedure existed before it was needed. Readers of the update that stopped the world will recognize the shape: concentration makes the ordinary days cheaper and the bad days synchronized.

The reflexive conclusion is repatriation: run Jenkins again, own the whole thing. I am mostly against. The median organization gets better availability from GitHub's build service than from the build server it would actually operate, as distinct from the one it imagines operating, and the industry did not move to hosted CI out of laziness. The boxes under the desks were worse.

The cheaper response is to treat 6 August as an audit nobody had to schedule, in the spirit of the audit that found the architecture. Every team that waited out the queue now knows its hour-six procedure, or knows that it does not have one. That knowledge cost the industry one afternoon, and it decays. The measurement was taken either way; the only question is whether anyone writes it down.