GitHub-Ausfall am 17. August: Downloads, Actions und Copilot betroffen – das ist bekannt

Die Störung breitete sich anschließend auf zahlreiche Dienste aus, die Entwicklerteams für den Zugriff auf Quellcode, Code-Reviews, automatisierte Tests und Auslieferungen benötigen. GitHub Actions, Pull Requests, Issues, Webhooks, Pages und Git-Operationen waren zu unterschiedlichen Zeitpunkten beeinträchtigt oder nicht verfügbar.

In einem Update um 12:36 Uhr EDT teilte GitHub mit, man habe die problematische Komponente identifiziert und Korrekturmaßnahmen ergriffen. Die Plattform zeigte demnach deutliche Anzeichen einer Erholung, war aber noch nicht vollständig stabil.

Die Wiederherstellung erfolgte nicht überall gleichzeitig. Während mehrere zentrale Dienste wieder als funktionsfähig galten, bestanden bei Copilot in einigen Anwendungen weiterhin Authentifizierungsprobleme. Andere Incident-Tracker ordneten das Ende der Gesamtstörung gegen 21:15 Uhr UTC ein. Damit dauerte der gesamte Vorfall deutlich länger als die erste Phase der besonders starken Beeinträchtigungen.

Wie groß war der Schaden?

Die wichtigsten von GitHub genannten Werte im Überblick:

• Web-Erlebnis und API-Verkehr: etwa 20 Prozent fehlerhafte Anfragen.
• Archiv-Downloads und rohe Repository-Inhalte: etwa 50 Prozent fehlerhafte Anfragen.
• Entwicklerdienste: Pull Requests, Issues, Actions, Webhooks, Git-Operationen und Pages waren zeitweise eingeschränkt oder nicht verfügbar.
• KI-Programmierhilfe: GitHub Copilot war betroffen und blieb auch nach der Erholung mehrerer Kerndienste ein eigenes Problem.
• Unternehmensidentitäten: Berichte nannten Störungen bei SAML- und OIDC-Anmeldung, SCIM-Bereitstellung und Team Sync. Unternehmen konnten Nutzer dadurch möglicherweise nicht zuverlässig anmelden oder Zugriffsrechte verwalten.

Die Zahlen lassen sich nicht direkt in „betroffene Nutzer“ umrechnen. Eine API-Fehlerquote von 20 Prozent bedeutet nicht, dass genau 20 Prozent der Kunden keinen Zugriff hatten. Ebenso beziehen sich die 50 Prozent auf die betroffenen Download-Anfragen – nicht auf den gesamten Datenverkehr aller Repositories.

Warum der Montagmorgen besonders ungünstig war

Der Ausfall begann an einem Montagmorgen in den USA und damit zum Start der Arbeitswoche vieler Engineering-Teams. In diesem Zeitfenster laufen häufig die ersten Code-Reviews, CI/CD-Prozesse, Tests und Deployments an. Da ausgerechnet Actions, Pull Requests, APIs und Webhooks betroffen waren, konnten Fehler mehrere miteinander verbundene Arbeitsschritte gleichzeitig treffen.

Auch die gemeldeten Zahlen von Ausfall-Trackern unterschieden sich je nach Zeitpunkt und Dienst. Ein Bericht sprach bis 8:12 Uhr pazifischer Zeit von mehr als 10.000 Downdetector-Meldungen. Ein späterer Bericht nannte einen Höchststand von knapp 3.000 Meldungen. Diese Werte sind keine präzise Nutzerstatistik: Downdetector erfasst eingereichte Meldungen, deren Zahl unter anderem von Region, Zeitpunkt und Messmethode abhängt.

Was GitHub unternommen hat – und was offenbleibt

Die öffentlichen Statusmeldungen belegen drei Schritte:

1. GitHub untersuchte erhöhte Fehler- und Latenzwerte über mehrere Dienste hinweg.
2. Das Unternehmen identifizierte eine problematische Komponente und leitete Korrekturmaßnahmen ein.
3. Nach der Erholung der wichtigsten Plattformdienste setzte GitHub weitere Maßnahmen um, unter anderem gegen sporadische Authentifizierungsfehler bei Copilot.

Nicht öffentlich bekannt sind bislang die genaue Komponente, die konkrete technische Korrektur und der vollständige Ablauf des Fehlers. Vor allem lässt sich aus den verfügbaren Informationen nicht belegen, dass Kapazitätsprobleme oder das Wachstum KI-basierter Workloads die bestätigte Ursache dieses konkreten Vorfalls waren. Beides gehört zur allgemeinen Zuverlässigkeitsdebatte bei GitHub, ist aber ohne das angekündigte Postmortem keine belastbare Erklärung für den Ausfall vom 17. August.

Ein weiterer Rückschlag in einem schwierigen Jahr

Der August-Vorfall folgte auf eine angespannte Zuverlässigkeitsphase. GitHubs Verfügbarkeitsbericht für Juli dokumentierte acht Vorfälle. Eine Störung am 8. Juli dauerte mehr als sieben Stunden und betraf unter anderem die Weboberfläche, REST- und GraphQL-API, Actions, Packages, Copilot und Git-Operationen in bestimmten Enterprise-Cloud-Umgebungen.

GitHub beschreibt zudem eine größere strukturelle Herausforderung: Der Datenverkehr wächst schnell, maßgeblich getrieben durch KI-gestützte und agentenbasierte Entwicklungsabläufe. Als Gegenmaßnahmen nannte das Unternehmen unter anderem zusätzliche elastische Kapazitäten in Azure, eine stärkere Trennung von Diensten und den Abbau gemeinsamer Fehlerquellen.

Bemerkenswert ist die Größenordnung der Planung. GitHub hatte ursprünglich eine Verzehnfachung der Kapazität vorgesehen. Bis Februar 2026 sei jedoch klar geworden, dass die Infrastruktur auf das 30-Fache der damaligen Größenordnung ausgelegt werden müsse. Weitere Berichte verwiesen auf zusätzliche Kapazitäten über Azure und eine Multi-Cloud-Strategie, zu der auch AWS gehören soll. Diese Pläne erklären den August-Ausfall allerdings nicht automatisch.

Was Unternehmen daraus ableiten sollten

Der Vorfall belegt weder, dass Entwickler GitHub nun massenhaft verlassen werden, noch lässt sich daraus eine unmittelbar bevorstehende Abwanderungswelle ableiten. Er zeigt aber, wie stark moderne Softwarebereitstellung von einer einzigen Plattform abhängen kann.

GitHub ist längst mehr als ein Ort zum Speichern von Git-Repositories: Die Plattform verbindet Quellcode, Zusammenarbeit, Automatisierung, Identitätsverwaltung und KI-Programmierhilfe. Wenn gemeinsame Abhängigkeiten ausfallen, können Repository-Zugriff, Reviews, Builds, Deployments, Webhooks und Copilot gleichzeitig beeinträchtigt werden.

Für Organisationen mit produktionskritischen GitHub-Workflows sind daher einige Vorkehrungen sinnvoll:

• Backups oder Spiegel-Repositories vorhalten,
• CI/CD-Konfigurationen portabel dokumentieren,
• Notfallprozesse für Releases festlegen,
• Abläufe ohne SSO, Webhooks oder gehostete Runner testen,
• Zuständigkeiten und alternative Kommunikationswege klären.

Diese Maßnahmen beseitigen das Plattformrisiko nicht. Sie können aber den Schaden begrenzen, wenn der nächste Ausfall nicht nur eine einzelne Funktion, sondern mehrere miteinander verknüpfte Arbeitsabläufe trifft.

Das abschließende Urteil über den 17. August wird von GitHubs Postmortem abhängen. Bis dahin bleibt eine engere, aber belastbare Schlussfolgerung: GitHub erlebte eine weitreichende, kaskadierende Dienststörung mit besonders starken Auswirkungen auf Repository-Downloads und verbundene Entwickler-Workflows. Die Dienste kamen schrittweise zurück – die grundlegende Ursache ist öffentlich jedoch noch nicht erklärt.