GitHub's Saturday Incident, and the Three Layers Between the Cause and What You Saw

On Saturday 13 September 2026, from 09:16 to 10:44 UTC, GitHub had what its status page classed as a critical incident: API requests, Issues, Pull Requests, Actions and Pages all degraded for eighty-nine minutes. It was resolved by mid-morning in Europe and before most of the United States was awake, and a detailed root cause analysis is promised. This is not that analysis, and it does not guess at what the analysis will say.

What it is about is one sentence GitHub posted twenty minutes into the incident, because that sentence is a better teaching example than most postmortems manage.

The line worth reading twice

At 09:36 UTC the status page said:

We’re seeing increased database replication delays on collab which is causing increased error rates in authorization endpoints and follow-on increased error rates across the system.

Read it as a chain. A database cluster fell behind on replication. That made the endpoints which decide whether you are allowed to do something start failing. And because nearly everything asks that question before it does anything, nearly everything started failing too.

Three layers: the cause, the thing the cause broke, and the things that broke because of that. Only the last layer was visible to anyone outside GitHub.

What it looked like from where you were standing

If you were working on Saturday morning, you did not see a replication delay. You saw one of these:

• A 403 from the API on a request that worked yesterday.
• A pull request page that would not load, or loaded without its checks.
• An Actions run that died with an error about permissions, or about nothing in particular.
• Pages not deploying.

None of those says “a database is behind”. Every one of them says something closer to “your account, your token, or your code is wrong”. A 403 in particular is the error that tells you it knows who you are and the answer is no, which is a very specific-sounding message to receive because a replica somewhere is a few seconds stale.

That is the general shape, and it is worth naming: the error you see is a symptom, and the symptom can be several layers from the cause. The layers are not deceit. Each system in the chain reported honestly what it saw. The authorization endpoint genuinely could not confirm you were allowed; the API genuinely had to refuse. The message was true at every step and useless at the last one.

Why this matters more than the outage did

Eighty-nine minutes on a Saturday is a small incident, and GitHub handled it well: a status entry within minutes, a cause stated inside twenty, load shedding to recover rather than waiting for the replica to catch up on its own, and a promise of the full analysis. That is what good looks like, and it is worth saying so.

The reason to write it up is that the same three-layer shape is underneath most of the bugs that get reported badly, and Saturday is an unusually clean specimen of it.

When somebody says “I got a 403”, they are reporting layer three. When a developer reads “403” and starts checking the person’s permissions, they are debugging layer two. The cause was in layer one, in a place neither of them could see, and neither the report nor the investigation will reach it by reasoning from the message. The message is the category. It is not the case. The whole family of HTTP errors works this way: each one names a kind of failure and withholds the particular one.

What closes the gap is not a better interpretation of the code. It is the surrounding facts: which request, at what time, alongside what else. On Saturday the surrounding fact was that everybody was seeing it at once, which is the question the earlier piece on telling your bug from their outage is built around and does not need repeating here.

What to write down when it is not everybody

The harder case is the one that is not on anybody’s status page. Your own system has the same layers: a slow query making a service time out making a page fail. The person who hits it gets layer three, and what they write down decides whether anyone can walk back to layer one.

So the useful report is not a diagnosis. It is the symptom stated exactly, with its time and its context, and no theory attached. “403 from /repos/x/y/pulls at 09:41 UTC, three retries, the same call succeeded at 08:50” is a report somebody can line up against a replication graph. “I think my token expired” is a theory that sends them to the wrong layer.

The network log is the exact request, the exact status, and the exact minute, captured without anybody having to decide which layer they think they are looking at. That is the material a root cause analysis is built from, whether it is GitHub’s or yours.

In one paragraph

On 13 September 2026 GitHub was degraded for eighty-nine minutes, and its own status page named the shape of it in one sentence: a database replication delay in one cluster caused failures in authorization endpoints, which caused failures across the system. Three layers, and only the last was visible from outside, as 403s and pages that would not load. The lesson is not about GitHub, which handled it well and owes nobody an apology. It is that the error you see is a symptom that can sit several layers from its cause, so the report that helps is the symptom stated exactly, with its time and context, rather than a theory about what it means.