Wo GitHub tatsächlich ausgefallen ist

Vertraute Situation: Du versuchst, Code zu pushen oder Actions zu prüfen, und bekommst als Antwort Stille oder einen 500-Fehler. Du gehst auf die offizielle Statusseite, und alles leuchtet grün, es heißt „Alle Systeme operativ“. Erst eine halbe oder ganze Stunde später erscheint ein bescheidener Banner über einen Incident.

Ich habe es immer amüsant gefunden, wie große Plattformen wissen, wie man Uptime-Statistiken „glättet“. Wenn man den offiziellen Berichten vertraut, ist GitHub почти immer mit 99,9% verfügbar. Aber Entwickler, die den Service jeden Tag nutzen, wissen: Die Realität ist viel prosaischer. Das github-statuses-Projekt ist ein Versuch, die historischen Aufzeichnungen richtigzustellen und zu zeigen, wie die Verfügbarkeit für die wichtigste Code-Schmiede tatsächlich aussah.

Worum es bei diesem Projekt geht

Der Repository-Autor hat beschlossen, schöne Grafiken nicht einfach hinzunehmen und die „fehlende Statusseite“ erstellt. Es ist ein Archiv, das Daten aus GitHubs Atom-Feeds sammelt und die echte Chronologie der Incidents rekonstruiert.

Das Projekt ist interessant, weil es nicht nur den aktuellen Zustand spiegelt – es speichert die Geschichte. Wenn GitHub einen alten Incident löscht oder seine Startzeit anpasst (was vorkommt), behält dieses Repository die ursprüngliche Spur. Das Projekt wurde bereits von großen Tech-Publikationen wie The Register und beliebten Bloggern wie Fireship und PrimeTime bemerkt. Es scheint, dass das Thema „GitHub-Ausfälle“ für viele ein wunder Punkt war.

Wie es unter der Haube funktioniert

Die Grundlage ist das Flat-Data-Konzept. Daten werden von einer externen Quelle abgerufen, verarbeitet und direkt im Repository als einfache Textdateien (JSON, CSV) gespeichert.

Ein interessantes Detail: Manchmal „vergisst“ GitHub anzugeben, welche Komponenten in einer Incident-Beschreibung betroffen waren. Um dieses Problem zu lösen, hat der Autor GLiNER2 angebunden – ein kleines Named-Entity-Recognition-Modell (NER). Es analysiert den Nachrichtentext und bestimmt, worüber gesprochen wird: Actions, Copilot oder API-Probleme.

Der Tech-Stack sieht folgendermaßen aus:

• Python 3.11–3.13 für Extraktionsskripte.
• uv als Paketmanager (der Autor empfiehlt es stark, und ich stimme zu – es funktioniert blitzschnell).
• GitHub Actions für die Automatisierung der Datensammlung.
• Eine einfache statische HTML/JS-Website, die die gesammelten Daten visualisiert.

Was du aus den Daten extrahieren kannst

Wenn du das Repository klonst, enthält der Ordner parsed/ bereits gebrauchsfertige Daten. Aber wenn du selbst damit experimentieren möchtest, ermöglichen die Skripte dir:

1. Alle Incidents für einen bestimmten Zeitraum im JSONL-Format zu exportieren.
2. Die Daten mit Impact-Level-Informationen anzureichern – dafür ruft das Skript die spezifischen Incident-Seiten auf und parst sie.
3. Ein CSV mit Ausfallzeiten zu generieren, das du einfach in Excel oder Grafana einfügen kannst, um eigene Diagramme zu erstellen.

Um alles davon auszuführen, brauchst du nur ein paar Befehle:

uv venv --python 3.13
uv sync
uv run python scripts/extract_incidents.py --out my_data --enrich-impact

Warum das für Entwickler nützlich ist

Auf den ersten Blick scheint es nur eine „Wall of Shame“ zu sein. Aber das Projekt hat durchaus praktische Anwendungen.

Erstens ist es ein großartiges Beispiel für die Arbeit mit unstrukturierten Daten. Schau dir an, wie der Autor einen ML-Fallback-Mechanismus implementiert hat, wenn das normale HTML-Parsing fehlschlägt. Im Code kannst du sehen, wie man Confidence-Thresholds für das Modell konfiguriert und wie man False Positives herausfiltert.

Zweitens, wenn du in einem Unternehmen arbeitest, in dem die GitHub-Abhängigkeit kritisch ist (zum Beispiel Deployment durch Actions alle 5 Minuten), können diese Daten dem Business dabei helfen, die Notwendigkeit zu rechtfertigen, Self-hosted Runner oder ein Backup auf GitLab/Bitbucket einzurichten. Zahlen von einer unabhängigen Quelle sind immer überzeugender als „Na ja, ich glaube, es fällt oft aus“.

Wie du die Ergebnisse ansehen kannst

Das Beste daran ist, dass du nichts konfigurieren musst, um die Diagramme anzusehen. Das Repository hat einen Ordner site/. Du kannst einfach einen lokalen Server starten:

python -m http.server 8000

Und http://localhost:8000/site/ öffnen. Du wirst Timelines sehen, Uptime-Prozentsätze für spezifische Services (Actions, Pages, Copilot) und eine detaillierte Aufschlüsselung nach Tag.

Das github-statuses-Projekt ist nicht nur ein Bug-Archiv. Es ist ein gutes Beispiel dafür, wie man mit Python, ein paar ML-Bibliotheken und GitHub Actions ein transparentes Monitoring-System erstellen kann, wo offizielle Quellen lieber schweigen.

Wer das Repository besuchen sollte:

• Diejenigen, die sich für Open-Data-Sammlung und -Analyse interessieren (Open Data).
• Entwickler, die die uv-Bibliothek in einem echten Projekt ausprobieren möchten.
• SRE-Ingenieure zur Risikobewertung bei der Nutzung von Cloud-Services.

Das Projekt lebt, Daten werden regelmäßig aktualisiert, und der Code ist sauber genug geschrieben, um ihn an einem Abend zu verstehen. Du kannst sogar versuchen, diese Skripte anzupassen, um andere Services zu überwachen, die dir wichtig sind.