Ich habe eine Seite gebaut, die genau eine Frage beantwortet: Läuft GitHub. Sie liest GitHubs offiziellen Statusfeed und zeigt die Antwort auf einem Spielautomaten. Hebel ziehen, Walzen laufen, Antwort.
Interessant ist der Teil, der während einer Störung passiert. Dann öffnet sich eine gemeinsame Runde. Alle auf der Seite sammeln denselben Pool, und wenn GitHub zurück ist, bekommt jeder, der dabei war, ein nummeriertes Ticket für genau diese Störung. Platz 392 von 1.438. Später bekommt man keins mehr.
Das ganze Ding steht auf einer Annahme: dass eine große GitHub-Störung selten ist. Ein Ticket, das man später nicht mehr bekommt, ist nur etwas wert, wenn „später“ der Normalfall ist.
Ich habe nachgesehen und lag falsch herum.
Was GitHubs eigener Feed sagt
Abgerufen am 18. August 2026 aus GitHubs Incident-Historie. Die API gibt die letzten 50 Incidents zurück, bei GitHub deckt das den 17. Juni bis 18. August ab, also 62 Tage.
- 50 Incidents in 62 Tagen, und das ist eine Untergrenze und keine Zählung, weil die API bei 50 aufhört
- 19 davon waren major oder critical: 11 major, 8 critical
- Diese 19 summieren sich auf 50 Stunden und 45 Minuten Incident-Zeit
- Also im Schnitt alle 3,3 Tage eine Störung, die ein Ticket auslöst
Die drei längsten dauerten 642, 558 und 456 Minuten. Die mit 456 Minuten war gestern.
Meine Einschätzung, und es ist eine Einschätzung: zwei Monate sind ein kurzes Fenster, und ich weiß nicht, ob dieser Sommer für GitHub normal ist. Aber der Abstand zwischen meiner Annahme und dem Feed ist zu groß für Zufall. Ich habe ein Sammelobjekt um ein Ereignis gebaut, das ich für außergewöhnlich hielt, und im sichtbaren Fenster ist es ein Dienstag.
Denselben Fehler habe ich schon mal in anderer Verkleidung gemacht: einem grünen Häkchen vertrauen, weil es grün war und nicht, weil ich wusste, was es prüft. Hier war es schlimmer, weil ich die Annahme nie ausgesprochen habe. Sie hat einfach getragen.
Die Schwelle war ohnehin die interessante Entscheidung
Ein Detail aus dem Bau, das ich aus einem Grund gemacht habe und das sich aus einem anderen als richtig herausstellt.
Die Maschine meldet jede Beeinträchtigung als down, weil das ehrlich zur Statusseite ist und weil man genau deswegen vorbeikommt. Ein Ticket entsteht aber nur bei major oder critical. Zwei Schwellen, mit Absicht.
Der Grund war banal: GitHub hat fast immer irgendetwas beeinträchtigt oder eine Wartung offen. Hätte ich darauf geprägt, wären ständig Tickets entstanden. Die Zahlen sagen dasselbe deutlicher, als mir lieb ist: 29 der 50 waren minor. Mit einer einzigen Schwelle wäre das seltene Ding mehrmals pro Woche gekommen und hätte nichts mehr bedeutet.
Die strenge Schwelle war Vorsicht. Sie ist jetzt der einzige Grund, warum von der Seltenheit überhaupt etwas übrig ist.
Was ich nicht kann, und warum mich das ärgert
Der kritische Incident von gestern dauerte 456 Minuten. Er kann nicht Störung #1 werden.
Aufgezeichnet wird nur, was ein Cron-Job im 60-Sekunden-Takt sieht, und der lief noch nicht. Eine Störung vor dem ersten Poll ist nicht nachtragbar. Es gibt keine Startzeit, der ich traue, und vor allem keine Aufzeichnung darüber, wer dabei war. Also gibt es auch niemanden, dem ein Ticket gehört.
Das war mir beim Bauen klar, deshalb ist die aufzeichnende Hälfte vor allem Sichtbaren fertig geworden. Trotzdem ärgerlich, einer sauberen Sieben-Stunden-Störung ungezählt hinterherzusehen.
Die Nummerierung fängt mit der nächsten bei 1 an.
Next
Gelaufen ist der Mechanismus noch nie. Nach den Zahlen oben wird das nicht lange so bleiben. Wenn die letzten 62 Tage etwas heißen, passiert es diese Woche.
Was mich wirklich interessiert: macht der gemeinsame Zähler das, was ich glaube. Meine Vermutung ist, dass eine Zahl gemeinsam mit ein paar hundert Leuten wachsen zu sehen etwas anderes ist, als allein eine Statusseite neu zu laden. Das ist allerdings die Vermutung eines Designers über einen Raum, in dem noch nie jemand war.
Falls du schon mal etwas gebaut hast, dessen ganze Prämisse auf einer Annahme stand, die du nie geprüft hast, würde ich gern hören, wie das ausgegangen ist. Meine hat überlebt, aber nur, weil eine Entscheidung aus einem ganz anderen Grund sie zufällig aufgefangen hat.
Zahlen am 18. August 2026 aus GitHubs öffentlicher Incidents-API. Sie gibt die letzten 50 Incidents zurück, die Zählungen sind also Untergrenzen. Dauern sind resolved_at minus created_at, wie GitHub sie meldet.
Baust du an etwas Ähnlichem?
Ich schreibe hier über Setups, die ich selbst benutze. Wenn du an etwas Vergleichbarem arbeitest, würde mich interessieren, wie dein Workflow aussieht.