On the outage that came back ninety-six minutes later

On 7 October 2026 GitHub recorded widespread impact across its services between 15:06 and 15:16 UTC: Git operations, pull requests, issues, webhooks and Actions, all at once, for ten minutes. By 16:23 the root cause had been identified and mitigations were being applied. At 16:52 it happened again, for nine minutes, and the status page said something unusual in its own voice: "This incident is a reoccurrence of the incident from earlier in the day."

Two words in those updates deserve definitions, because they are routinely used as synonyms and are not. A mitigation reduces the impact of a cause that is still present. A fix removes the cause. Restarting the saturated process is a mitigation; finding out why it saturated at that minute of that day is the beginning of a fix. The first update promised mitigations "to prevent a reoccurrence". The second, after the reoccurrence, promised that "durable mitigation is in progress", and the adjective is the admission.

None of this is a criticism of the response. Nineteen minutes of total impact in an afternoon is a good day by the standards of the industry's worst ones, and the August outage, which I wrote about in ten hours without CI, was fifty times longer. The interest here is in the interval. Ninety-six minutes is about how long it takes a large organization to declare victory, write the internal summary and return the responders to their day. The system did not read the summary.

Anyone who has read old postmortems will know the pattern: the second occurrence is the one that gets the real investigation, because a single incident can be filed under weather and a repeat cannot. The useful discipline is to behave after the first one as though the second is already scheduled.

The root cause analysis has been promised. When it arrives, the question to read it for is not what broke. It is what happened at 16:52 that the 16:23 mitigation was supposed to prevent.