Am 17. August 2026 war GitHub sieben Stunden und siebenundvierzig Minuten lang nicht erreichbar. Authentifizierung, Actions, die API, Pull Requests, Issues und Copilot fielen mit aus, und sehr viele Teams verbrachten einen Teil dieses Nachmittags damit herauszufinden, ob ihr eigener Build kaputt war.

Diese Frage - liegt es an uns oder an denen - sollte man in zwei Minuten beantworten können und nicht in zwei Stunden, und die Belege, die sie beantworten, verschwinden mit dem Ende des Vorfalls.

Die Belege, in der Reihenfolge, in der sie helfen

Welcher Host ausfällt. Öffnen Sie den Netzwerk-Tab und sehen Sie nach, wohin die fehlschlagenden Anfragen gehen. Ein 500 von Ihrer eigenen Domain gehört Ihnen. Ein 503 von einer API, die Sie nicht betreiben, gehört Ihnen nicht, so sehr es auch danach aussieht, dass Ihre Funktion kaputt ist. Das klingt offensichtlich und ist der Schritt, den man überspringt, weil das Symptom in Ihrer Oberfläche auftaucht und die Oberfläche das ist, worauf man schaut.

Was der Statuscode sagt. Ein 401 oder 403 während des Authentifizierungsvorfalls von jemand anderem ist kein Berechtigungsfehler in Ihrem Code, und genau der wird am häufigsten als einer abgelegt. Ein 429 ist ein Rate Limit und kann eine Folge Ihrer eigenen Retries sein. Ein Timeout ganz ohne Antwort deutet öfter nach außen als nach innen.

Ob es mit Ihrem Deploy zusammenfällt. Die erste Frage in jedem Incident-Channel lautet, was sich geändert hat. Wenn Ihr letztes Release drei Stunden vor Beginn der Symptome lag, ist das in der ersten Nachricht erwähnenswert und nicht erst in der fünften.

Was die Statusseite sagt, als Zweites geprüft und nicht als Erstes. Statusseiten werden von Leuten gepflegt, die gerade damit beschäftigt sind, dass alles brennt, und sie hinken dem Ausfall ein paar Minuten hinterher. Ihr eigener Netzwerk-Tab weiß es vor deren Statusseite.

Die Falle: Ihre Retries können es schlimmer machen

Der Teil von GitHubs Schilderung, den man zweimal lesen sollte, ist das, was während der Erholung passierte. Ihr eigener Postmortem sagt:

Fehler in diesen Diensten lösten eine clientseitige Retry-Schleife aus, die den Traffic während der Wiederherstellung erhöhte. Wir mussten dieses Verhalten eindämmen, bevor wir den Traffic gefahrlos wieder zulassen konnten.

Die Clients, die sich am meisten anstrengten durchzukommen, gehörten also mit dazu, dass die Tür zu blieb. GitHubs Liste der Maßnahmen benennt die Abhilfe allgemein - “einheitliche Retry-Limits, Retry-Budgets und variable Timeouts über alle Service-zu-Service-Aufrufe hinweg, um Retry-Stürme und kaskadierende Last zu verhindern” - und das ist ein Satz, den man gegen den eigenen Code halten sollte.

Retry-Logik, die für eine einzelne fehlgeschlagene Anfrage geschrieben wurde, verhält sich anders, wenn jede Anfrage fehlschlägt. Ohne Budget, ohne Backoff und ohne Jitter werden hundert Instanzen, die alle nach demselben Zeitplan erneut anfragen, zu einem synchronisierten Lasttest auf einen Dienst, der ohnehin schon zu kämpfen hat.

Ebenfalls wissenswert: Keiner der beiden GitHub-Vorfälle im August kam von einer Code- oder Konfigurationsänderung. Beide waren Kapazitätsprobleme. Der Reflex, nach dem Deploy zu suchen, der es ausgelöst hat, ist meistens richtig und war hier falsch.

Erfassen Sie es, solange es kaputt ist

Ein Ausfall ist die eine Sorte Defekt, die sich selbst repariert, und die Belege gehen mit ihm. Zwei Stunden später liefert die Anfrage, die einen 503 zurückgab, einen 200, und im Ticket steht für den Rest seines Lebens “sporadischer Fehler, nicht reproduzierbar”.

Was Sie brauchen, aufgenommen während des Vorfalls: die fehlschlagenden Anfragen mit ihren Statuscodes und Zeiten, die Konsolenausgabe und der Zeitpunkt, zu dem jede einzelne passierte.

Session Replay

Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link, den Sie ins Ticket einfügen können.

Erweiterung holen

Das Netzwerkprotokoll enthält eine HAR-Datei, also genau das Artefakt, nach dem der Support von jemand anderem Sie ohnehin fragen wird. Bereinigen Sie sie, bevor Sie sie weitergeben: Eine mit Inhalten gespeicherte HAR-Datei trägt Session-Cookies und Authorization-Header, und das ist das eine an diesem Ablauf, das bei einer anderen Firma bereits zu einem Leck geführt hat.

Es so aufschreiben, dass es nicht falsch abgelegt wird

Ein Incident-Bericht und ein Fehlerbericht sind zwei verschiedene Dokumente, und sie zu verwechseln kostet einen Entwickler den Vormittag.

Wenn der Ausfall bei jemand anderem liegt, schreiben Sie das in den Titel, und schreiben Sie dazu, was es für Sie bedeutet: welche Funktion betroffen ist, ob es einen Workaround gibt und worauf Sie warten. “Checkout schlägt fehl - vorgelagerter Zahlungsanbieter liefert seit 14:10 ein 503, kein Workaround, deren Statusseite bestätigt es” ist ein vollständiger Bericht. Niemand muss das reproduzieren, und niemand sollte es versuchen.

Wenn es Ihres sein könnte, ist es ein gewöhnlicher Fehlerbericht und will die gewöhnlichen Dinge: was Sie erwartet haben, was passiert ist, die Umgebung und die Belege. Unser Leitfaden zum Schreiben eines solchen Berichts hat die Form, und die zehn häufigsten Fehler decken ab, was üblicherweise fehlt.

Und wenn Sie es wirklich noch nicht wissen, schreiben Sie das. “Unklar, ob es an uns liegt - die fehlschlagenden Anfragen gehen an einen externen Host, aber unser Release ging um 13:30 raus” ist nützlicher als eine selbstbewusste Vermutung in die eine oder andere Richtung.

Danach

Zwei Fragen, die sich nach dem Vorfall lohnen, solange sich die Leute noch erinnern.

Wie lange haben wir gebraucht, um zu wissen, dass es nicht an uns lag? Wenn die Antwort eine Stunde ist, liegt die Lösung meist in der Sichtbarkeit und nicht in der Ausfallsicherheit: irgendwo hinsehen können, wo steht, welche Hosts gerade ausfallen.

Haben unsere Retries geholfen oder geschadet? GitHub musste das Verhalten der Clients eindämmen, bevor der Traffic wieder laufen konnte. Ihre Clients sind das Client-Verhalten von jemand anderem.

Quellen: GitHubs eigene Schilderung des Vorfalls steht unter The August 17 outage, and the work ahead, und sie ist ungewöhnlich konkret darin, was schiefging. Ihnen hoch anzurechnen, dass sie veröffentlicht wurde, und hier zitiert, weil ein Postmortem, das Retry-Stürme beim Namen nennt, nützlicher ist als jeder Ratschlag darüber.