GitHub was degraded for seven hours across five services. Its status page posted 37 updates and named a cause in none of them

What the status page has published, and what it has not

At 13:40:03 UTC on 17 August 2026, GitHub opened incident zkxwbgr0cnmx with one sentence: it was investigating reports of impacted performance for some services. Five minutes later it published the size of the problem.

We are seeing an approximate 20% error rate across numerous experiences including Pull Requests, Issues, and others.

By 14:04 that statement had grown a second figure, an approximate 50% error rate on archive downloads and raw repository content, and by 14:24 a third clause naming SAML and OIDC authentication, SCIM and Team Sync. Those three sentences have been repeated without material change ever since.

Nineteen updates had been posted by 15:21 UTC. Fourteen of them named a component. Five described the aggregate. None named a cause. The incident was still marked investigating two hours after it opened, which is the status it carried when this was first written at 15:38 UTC.

By 16:36 UTC the count had reached twenty-eight and the status had moved to monitoring. The incident closed at 21:15:46 UTC on 37 updates, seven hours and 36 minutes after it opened. No update in that sequence named a cause, and the two that came closest are quoted in full below.

That is not a complaint about the engineers, who are working the problem, and an incident page written during an incident is not a post-incident report. It is an observation about what the document is able to say while the thing it describes is still happening, which is the only time anybody actually reads it.

The component list disagrees with the paragraph above it

GitHub publishes the same incident twice, in two formats, and they do not describe the same service.

The prose says roughly one request in five is failing. The machine-readable component list, read from GitHub's own API at 15:38 UTC, says five components are in major_outage, which in Atlassian Statuspage vocabulary is the most severe state below a full outage and sits two steps above degraded_performance.

Both readings are published by GitHub, about one event, at one moment, on one page. A reader who takes the prose comes away thinking most things work. A reader who takes the component list comes away thinking five of the twelve tracked services are effectively down. The overall indicator on the same API call reads Partial System Outage with an impact of critical.

The gap is not dishonesty. It is that a percentage and a state are answers to different questions, and the page publishes both without saying which one to use.

A push succeeded while Git Operations was listed as degraded

Git Operations was named last, at 15:21, which is 101 minutes after the incident opened and 96 minutes after GitHub had already published the 20% figure. Seventeen minutes after that listing appeared, a real operation against a real repository returned normally.

$ time git ls-remote --heads origin main

64b892dbb98cf77bc249633e0d724f8e0113f65b  refs/heads/main
git ls-remote --heads origin main  0.03s user 0.03s system 6% cpu 0.888 total

One operation, at one moment, from one network. That proves nothing about the fleet, and it is not offered as a rebuttal. It is offered because it is the exact experience that makes a status page feel wrong to the person reading it: the page says degraded, the terminal says fine, and neither is lying.

A component status is a global aggregate. The question a developer has at 15:38 is not what proportion of the fleet is erroring. It is whether the push about to be run will land, and no aggregate can answer that. During a 20% error event, the honest answer to an individual is that four operations in five will work and the fifth will fail in a way that looks like nothing in particular.

The recovery message identifies a component and does not name it

At 16:36 UTC, two hours and fifty-six minutes after the incident opened, GitHub moved it from investigating to monitoring.

We identified the problematic component and have taken corrective actions. There are strong signs of recovery but we are still working to completely restore service, with error rates still remaining slightly elevated.

That is the twenty-eighth update and the first to assert that anybody knows what is wrong. It does not say which component, what was wrong with it, or what the corrective action was. In one respect it is the most useful thing on the page all afternoon, because strong signs of recovery is information that genuinely was not available at 15:38 and it changes what a reader should do next. In the other respect it withholds the causal layer completely, and the phrase doing the withholding is the problematic component.

The page has now named a component fourteen times and identified a cause once, in the abstract, without saying what it was. That sequence arrived after this piece was written rather than being selected to fit it, which is the only reason it is worth pointing at. A post-incident report may eventually say more. The status page, which is the document anybody actually read this afternoon, did not.

At 21:15:46 UTC it closed, on the thirty-seventh update, seven hours and 36 minutes after opening:

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

So the count finishes where it started. Thirty-seven updates, a component named in most of them, a cause named in none, and the causal account deferred to a document with no publication date attached to it. The last twenty minutes before closure were spent on sporadic Copilot authentication failures, which is the most specific technical detail the page produced all day and arrived after everything else had recovered.

Fifteen incidents in seventeen days

This is not an unusual month made visible by one bad afternoon. GitHub's own incident history, read from /api/v2/incidents.json, lists fifteen separate incidents between 1 and 17 August 2026. Two carry an impact of critical: an Actions incident on 6 August that ran from 15:22 to 02:04 the following morning, and this one.

Fifteen incidents in seventeen days is roughly one every twenty-seven hours. Most were minor and most closed quickly. The point of counting them is that the status page is where a customer is expected to form a view of reliability, and a page that reports each incident in isolation is a poor instrument for that. Nothing on it aggregates.

The third instrumentation story this week

Read on its own this is an outage, and outages are not interesting. Read against the two briefings published on this site earlier today, it is the same defect in a third form.

In all three, the published artefact describes the visible surface and omits the mechanism underneath it. Anthropic's classifier gap was invisible because the control and its telemetry shared a switch. OpenAI's framework survived the dissolution of a team because it never named the team. GitHub's status page reports that Pull Requests are in major_outage and has said nothing in two hours about what is producing that.

This is the weaker of the three cases and it should be said plainly. GitHub is in the middle of a live incident and owes nobody a root cause at ninety minutes. The other two are settled documents describing steady states. What connects them is narrower: each publishes component health and withholds, by design rather than by accident, the causal layer a reader would need to act on.

What the open window required, kept as written

This section was written at 15:38 UTC with the incident open and is left unchanged, because the point of it was what could be decided without a cause and that is the situation it describes.

The position

A status page is not a monitoring tool and was never built to be one. It is a communications surface, and the thing it is best at is publishing states that are cheap to compute and hard to dispute. major_outage is a defensible word. "Roughly one in five of your requests will fail for reasons we have not identified, and we do not know for how long" is the true sentence, and no status page has ever printed it.

The practical consequence is that during an incident the reader is doing the causal work themselves, from a component list, in the middle of the disruption the list is describing. That is the wrong time and the wrong instrument, and it is why the first thing most teams do in an outage is check somewhere other than the status page.