GitHub Ausfall 17 August 2026: Das offizielle Postmortem
Am 17. August 2026 legte ein Kapazitätsproblem in einem einzigen US-Rechenzentrum GitHub für 7 Stunden und 47 Minuten lahm – Website, Anmeldung, Actions, Pull Requests, Issues und Copilot waren betroffen. Drei Tage später veröffentlichte CTO Vlad Fedorov ein ungewöhnlich offenes Postmortem. Für Unternehmen, deren Entwicklungsprozesse an einem einzigen Anbieter hängen, ist das mehr als eine technische Randnotiz.
Ein Kapazitätsproblem, das sich selbst verstärkte
Um 13:40 UTC bestätigte GitHub erste Performance-Probleme. Innerhalb von 18 Minuten waren API Requests, Actions, Webhooks und Issues betroffen, kurz darauf auch Pull Requests. Laut dem offiziellen Postmortem von CTO Vlad Fedorov begann der Vorfall, als die Traffic-Last einen neuen Höchststand erreichte und eine kritische Infrastrukturkomponente in GitHubs Rechenzentrum in Zentral-USA nicht mitskalierte. Der daraus entstehende Kapazitätsdruck breitete sich durchs System aus, verursachte Authentifizierungsfehler und beeinträchtigte mehrere GitHub-Dienste gleichzeitig – darunter auch SAML- und OIDC-Anmeldung, was für Unternehmen relevant ist, die GitHub als Identity Provider nutzen.
„Wenn Sie an diesem Tag versucht haben, Software auszuliefern, haben wir Sie im Stich gelassen. Weder der Ausfall am 6. August noch der am 17. August wurde durch eine Code- oder Konfigurationsänderung verursacht – beide waren im Kern Kapazitätsausfälle.“
— VLAD FEDOROV, CTO GITHUB · OFFIZIELLES POSTMORTEM, 20. AUGUST 2026Der zweite schwere Vorfall im selben Monat, in einem Jahr mit ungewöhnlichem Wachstum
Bemerkenswert an Fedorovs Postmortem ist die Offenheit, mit der GitHub den Kontext einordnet: Der 17. August war bereits der zweite schwere Vorfall im August, nach einem Actions-Ausfall am 6. August. Bereits im März und April hatte GitHub öffentlich über Zuverlässigkeitsprobleme berichtet. Der eigentliche Treiber hinter dem Druck auf die Systeme ist Wachstum in einem Tempo, das laut GitHub selbst schwer vorherzusehen war: Die monatlichen Commits stiegen seit April von 1,4 Milliarden auf 2,9 Milliarden – mehr als eine Verdopplung in wenigen Monaten, unter anderem getrieben durch den massiven Anstieg KI-gestützter Coding-Agenten und automatisierter Workflows.
Externe Auswertungen des GitHub-eigenen 90-Tage-Verfügbarkeits-Dashboards zeigen das Ausmaß: Die Verfügbarkeit von GitHub Actions fiel über 90 Tage auf 99,33 Prozent – unterhalb der „drei Neunen“ (99,9 %), die viele Enterprise-Verträge als Erwartungswert zugrunde legen. Damit hat allein der August-Ausfall einen Großteil des für das gesamte Jahr eingeplanten Ausfall-Budgets aufgebraucht. Git-Operationen selbst blieben mit 99,99 Prozent deutlich stabiler – ein Hinweis darauf, dass insbesondere die CI/CD-Schicht rund um Actions unter besonderem Druck steht, während der Kern-Git-Betrieb robuster bleibt.
Ein Anbieter, ein Rechenzentrum, ein Großteil der weltweiten Softwareentwicklung
GitHub ist für viele Unternehmen längst mehr als ein Ort zum Speichern von Code. Es ist CI/CD-Engine für automatisierte Deployments, Reviewer-Plattform für Pull Requests, Identity Provider für Unternehmens-Logins per SAML/OIDC und zunehmend auch KI-Coding-Assistent über Copilot. Genau diese Bündelung macht einen Ausfall wie den vom 17. August so weitreichend: Ein einziger DNS-Eintrag, ein einziges Rechenzentrum – und ein erheblicher Teil der Branche verlangsamt sich gleichzeitig.
Für Unternehmen im Rhein-Main-Gebiet, die ihre Entwicklungs-Pipelines, Authentifizierung oder Projektmanagement direkt an GitHub gekoppelt haben, bedeutet ein solcher Ausfall konkret: gestoppte automatisierte Deployments, verzögerte Code-Reviews, blockierte Unternehmens-Logins und unterbrochene KI-gestützte Coding-Sessions – gleichzeitig, ohne dass im eigenen Haus irgendetwas falsch gelaufen wäre. Das ist kein Grund für Panik, aber ein klares Argument dafür, Abhängigkeit von einem einzelnen externen Anbieter als reales Geschäftsrisiko einzuplanen, nicht als theoretisches.
Fünf praktische Lehren – unabhängig davon, welchen Anbieter man nutzt
GitHubs Postmortem ist ungewöhnlich transparent, und die Ursache – ein reines Kapazitätsproblem bei explosivem Wachstum, verschärft durch eine unkontrollierte Retry-Schleife – ist technisch nachvollziehbar und keine Grundlage für Alarmismus. Der eigentliche Wert des Vorfalls liegt woanders: Er zeigt in aller Deutlichkeit, wie viel geschäftliche Kontinuität heute an der Verfügbarkeit einzelner externer Plattformen hängt – auch bei Anbietern mit der Größe und den Ressourcen von GitHub und Microsoft. Für Unternehmen im Rhein-Main-Gebiet, die ihre Entwicklungs- und IT-Prozesse zunehmend auf Cloud-Dienste stützen, ist das kein Grund, diese Dienste zu meiden, sondern ein guter Anlass, die eigene Abhängigkeitskette einmal nüchtern durchzugehen: Wo genau würde es wehtun, wenn genau dieser eine Anbieter morgen für acht Stunden ausfällt – und existiert dafür bereits ein Plan?
IT REX Solutions ist an fünf Standorten für Sie da – vor Ort, persönlich, ohne lange Wartezeiten.
061318944180FAQ – GitHub-Ausfall vom 17. August 2026
Wie lange dauerte der GitHub-Ausfall genau?
Was war die Ursache des Ausfalls?
Welche GitHub-Dienste waren betroffen?
War es der einzige schwere GitHub-Ausfall in diesem Zeitraum?
Was unternimmt GitHub, um solche Ausfälle künftig zu verhindern?
Wie kann sich mein Unternehmen gegen ähnliche Ausfälle absichern?
Wüssten Sie, wie lange Ihr Unternehmen ohne GitHub, Cloud oder zentrale Anmeldung arbeitsfähig bliebe?
Wir analysieren Ihre kritischen Abhängigkeiten und entwickeln einen konkreten Business-Continuity-Plan – damit ein Ausfall bei einem externen Anbieter nicht zum Stillstand in Ihrem Unternehmen wird.
Notfallplanung anfragen →
