GitHubs Samstagsstörung, und die drei Schichten zwischen der Ursache und dem, was Sie gesehen haben

Am Samstag, dem 13. September 2026, hatte GitHub von 09:16 bis 10:44 UTC das, was seine Statusseite als kritische Störung einstufte: API-Anfragen, Issues, Pull Requests, Actions und Pages waren neunundachtzig Minuten lang beeinträchtigt. Sie war am Vormittag in Europa behoben, bevor der Großteil der Vereinigten Staaten wach war, und eine ausführliche Ursachenanalyse ist angekündigt. Dies ist nicht diese Analyse, und es rät nicht, was darin stehen wird.

Worum es hier geht, ist ein einziger Satz, den GitHub zwanzig Minuten nach Beginn der Störung veröffentlicht hat, denn dieser Satz ist ein besseres Lehrbeispiel, als es die meisten Postmortems zustande bringen.

Die Zeile, die es zweimal zu lesen lohnt

Um 09:36 UTC hieß es auf der Statusseite:

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.

Lesen Sie es als Kette. Ein Datenbank-Cluster geriet bei der Replikation in Rückstand. Dadurch begannen die Endpunkte auszufallen, die entscheiden, ob Sie etwas tun dürfen. Und weil fast alles diese Frage stellt, bevor es irgendetwas tut, begann fast alles auszufallen.

Drei Schichten: die Ursache, das, was die Ursache kaputt gemacht hat, und die Dinge, die deshalb kaputt gingen. Nur die letzte Schicht war für irgendjemanden außerhalb von GitHub sichtbar.

Wie es von dort aussah, wo Sie standen

Wenn Sie am Samstagmorgen gearbeitet haben, haben Sie keine Replikationsverzögerung gesehen. Sie haben eines von diesen gesehen:

• Einen 403 von der API auf eine Anfrage, die gestern noch funktionierte.
• Eine Pull-Request-Seite, die nicht lud, oder ohne ihre Checks lud.
• Einen Actions-Lauf, der mit einem Fehler über Berechtigungen starb, oder über gar nichts Bestimmtes.
• Pages, die nicht deployten.

Nichts davon sagt “eine Datenbank hängt hinterher”. Jedes davon sagt eher “Ihr Konto, Ihr Token oder Ihr Code ist falsch”. Gerade ein 403 ist der Fehler, der Ihnen sagt, dass er weiß, wer Sie sind, und die Antwort trotzdem nein ist, was eine sehr konkret klingende Nachricht ist, wenn man sie bekommt, weil irgendwo ein Replikat ein paar Sekunden veraltet ist.

Das ist die allgemeine Form, und sie verdient einen Namen: der Fehler, den Sie sehen, ist ein Symptom, und das Symptom kann mehrere Schichten von der Ursache entfernt liegen. Die Schichten sind kein Betrug. Jedes System in der Kette hat ehrlich gemeldet, was es gesehen hat. Der Autorisierungs-Endpunkt konnte wirklich nicht bestätigen, dass Sie berechtigt sind; die API musste wirklich ablehnen. Die Nachricht war auf jeder Stufe wahr und auf der letzten nutzlos.

Warum das mehr zählt als der Ausfall selbst

Neunundachtzig Minuten an einem Samstag sind eine kleine Störung, und GitHub hat sie gut gehandhabt: ein Statuseintrag innerhalb von Minuten, eine Ursache innerhalb von zwanzig genannt, Lastabwurf zur Erholung statt darauf zu warten, dass das Replikat von allein aufholt, und die Zusage der vollständigen Analyse. So sieht gut aus, und das sollte man auch sagen.

Der Grund, es aufzuschreiben, ist, dass dieselbe Drei-Schichten-Form unter den meisten Fehlern liegt, die schlecht gemeldet werden, und der Samstag ein ungewöhnlich sauberes Exemplar davon ist.

Wenn jemand sagt “ich habe einen 403 bekommen”, meldet er Schicht drei. Wenn ein Entwickler “403” liest und anfängt, die Berechtigungen der Person zu prüfen, debuggt er Schicht zwei. Die Ursache lag in Schicht eins, an einem Ort, den keiner von beiden sehen konnte, und weder die Meldung noch die Untersuchung erreicht sie durch Schlussfolgern aus der Nachricht. Die Nachricht ist die Kategorie. Sie ist nicht der Fall. Die ganze Familie der HTTP-Fehler funktioniert so: jeder benennt eine Art von Fehlschlag und verschweigt den konkreten.

Was die Lücke schließt, ist keine bessere Deutung des Codes. Es sind die umgebenden Fakten: welche Anfrage, zu welcher Zeit, neben was sonst. Am Samstag war der umgebende Fakt, dass alle es gleichzeitig sahen, und das ist die Frage, um die der frühere Beitrag zum Unterscheiden Ihres Bugs von deren Ausfall gebaut ist und die hier nicht wiederholt werden muss.

Was aufzuschreiben ist, wenn es nicht alle betrifft

Der schwierigere Fall ist der, der auf niemandes Statusseite steht. Ihr eigenes System hat dieselben Schichten: eine langsame Abfrage lässt einen Dienst in ein Timeout laufen, was eine Seite scheitern lässt. Die Person, die darauf trifft, bekommt Schicht drei, und was sie aufschreibt, entscheidet, ob jemand zurück zu Schicht eins gehen kann.

Die nützliche Meldung ist also keine Diagnose. Es ist das genau benannte Symptom, mit seiner Zeit und seinem Kontext, und ohne angehängte Theorie. “403 von /repos/x/y/pulls um 09:41 UTC, drei Wiederholungen, derselbe Aufruf ging um 08:50 durch” ist eine Meldung, die jemand gegen einen Replikationsgraphen halten kann. “Ich glaube, mein Token ist abgelaufen” ist eine Theorie, die ihn auf die falsche Schicht schickt.

Das Netzwerkprotokoll ist die genaue Anfrage, der genaue Status und die genaue Minute, erfasst, ohne dass jemand entscheiden musste, welche Schicht er gerade zu sehen glaubt. Das ist das Material, aus dem eine Ursachenanalyse gebaut wird, ob GitHubs oder Ihre.

In einem Absatz

Am 13. September 2026 war GitHub neunundachtzig Minuten lang beeinträchtigt, und seine eigene Statusseite hat die Form davon in einem Satz benannt: eine Replikationsverzögerung in einem Datenbank-Cluster verursachte Ausfälle in den Autorisierungs-Endpunkten, die Ausfälle im ganzen System verursachten. Drei Schichten, und nur die letzte war von außen sichtbar, als 403er und Seiten, die nicht luden. Die Lektion handelt nicht von GitHub, das es gut gehandhabt hat und niemandem eine Entschuldigung schuldet. Sie lautet, dass der Fehler, den Sie sehen, ein Symptom ist, das mehrere Schichten von seiner Ursache entfernt liegen kann, sodass die Meldung, die hilft, das genau benannte Symptom mit Zeit und Kontext ist, statt einer Theorie darüber, was es bedeutet.