Montagnachmittag, kurz vor 16 Uhr deutscher Zeit: Der Build läuft nicht mehr an. Der Push hängt. Das Issue lässt sich nicht öffnen. Und der Copilot-Vorschlag kommt einfach nicht.
GitHub war weltweit gestört — und mit der Plattform stand ein guter Teil der Software-Welt still. Über 10.000 Störungsmeldungen liefen allein bei Downdetector auf. Microsoft bestätigte den Ausfall.
WAS GENAU AUSGEFALLEN IST
Die Störung begann gegen 13:40 Uhr UTC (15:40 Uhr in Deutschland) und zog sich quer durch fast alle Kern-Dienste:
- API Requests — alles, was automatisiert auf GitHub zugreift
- Actions — CI/CD-Pipelines, Tests, Deployments
- Webhooks — Benachrichtigungen an andere Systeme
- Issues und Pull Requests — die Zusammenarbeit selbst
- Git Operations und Pages
Dazu kamen die Unternehmens-Anmeldeverfahren: SAML, OIDC, SCIM und Team Sync waren breit betroffen. Wer sich per Single Sign-on anmeldet, kam schlicht nicht mehr rein.
50 PROZENT FEHLER — warum diese Zahl so wehtut
Auf dem Höhepunkt meldete GitHub selbst rund 20 Prozent Fehlerrate bei Weboberfläche und API. Klingt überschaubar? Ist es nicht. Denn bei den Roh-Downloads von Repository-Inhalten und Archiven lag die Fehlerrate bei etwa 50 PROZENT — also jeder zweite Abruf.
Genau da hängt mehr dran, als die meisten auf dem Schirm haben. Jedes curl … | bash-Installskript. Jedes Docker-Image, das beim Bauen Quellen von GitHub zieht. Jedes go get, jedes pip install aus einem Git-Repo. Jeder Ansible-Lauf, der eine Rolle von GitHub holt.
Und ja: auch dein Homelab. Wer nachts automatisiert Container neu baut, hatte am Montag reihenweise rote Logs — ohne einen einzigen eigenen Fehler.
WANN ES WIEDER LIEF
Um 16:59 Uhr UTC erklärte GitHub die Störung für die sieben Kern-Dienste als behoben: API Requests, Actions, Git Operations, Issues, Pages, Pull Requests und Webhooks standen wieder auf „Operational“.
Ein Dienst fehlte in dieser Meldung allerdings: Copilot war zu diesem Zeitpunkt noch als „Major Outage“ markiert. Die KI-Hilfe kam also später zurück als der Rest.
DIE UNBEQUEME LEHRE: eine Plattform, ein Single Point of Failure
Der Ausfall ist kein Sicherheitsvorfall. Es sind keine Daten abgeflossen, nichts wurde kompromittiert. Aber er legt etwas offen, das viele verdrängen: Ein sehr großer Teil der weltweiten Software-Lieferkette hängt an einem einzigen Anbieter.
Und das betrifft nicht nur Konzerne mit tausend Entwicklern. Es betrifft jeden, der zu Hause ein paar Container laufen lässt.
SO MACHST DU DEIN SETUP UNABHÄNGIGER
Du kannst GitHub nicht ersetzen — aber du kannst dafür sorgen, dass ein Ausfall dich nicht lahmlegt. Vier Schritte, die sich an einem Nachmittag umsetzen lassen:
- Container-Images spiegeln. Ein lokaler Registry-Cache (etwa eine Pull-Through-Registry) hält die Images vor, die du täglich brauchst. Fällt die Quelle aus, läuft dein Stack trotzdem hoch.
- Abhängigkeiten festnageln. Version-Pinning und Lockfiles sorgen dafür, dass ein Build reproduzierbar bleibt — und du bei einem Ausfall nicht zusätzlich rätselst, welche Version eigentlich gerade drin ist.
- Wichtige Repos lokal klonen. Eine selbst gehostete Forgejo- oder Gitea-Instanz als Spiegel für die fünf Projekte, die dein Setup wirklich tragen, kostet fast nichts und rettet den Tag.
- Automatische Nacht-Builds entzerren. Wer Retries mit Backoff einbaut, verwandelt eine Störung in eine Verzögerung statt in eine Fehlermeldung.
EXTRA-TIPP: die Statusseite in dein Monitoring hängen
GitHub veröffentlicht seinen Dienststatus maschinenlesbar. Wer den Status in sein Dashboard einbindet, sieht beim nächsten Mal binnen Sekunden, ob das Problem beim Anbieter liegt — statt eine Stunde die eigene Pipeline zu debuggen.
FAZIT: kein Drama, aber ein Weckruf
Die Störung war nach gut dreieinhalb Stunden vorbei, ohne Datenverlust und ohne Angriff. Das ist die gute Nachricht.
Die schlechte: Es war nicht der erste Ausfall dieser Größenordnung, und es wird nicht der letzte sein. Wer daraus mitnimmt, seine wichtigsten Abhängigkeiten zu spiegeln, hat aus einem verlorenen Montagnachmittag etwas Bleibendes gemacht.