GitHubs 7-Stunden-Ausfall am 17. August: Was passierte und was kommt jetzt

Was passiert ist

Am 17. August erlebte GitHub einen 7-Stunden- und 47-Minuten-Ausfall, der github.com, Authentifizierung, GitHub Actions, APIs, Pull Requests, Issues und Copilot lahmlegte. Laut GitHub-CTO Vlad Fedorov war dies der zweite erhebliche Vorfall im August, nach einem Actions-Ausfall am 6. August.

Die Ursache war kein Code- oder Konfigurationsfehler — sondern schlichtweg ein Kapazitätsproblem. Bei einem Traffic-Peak versagte eine kritische Infrastruktur-Komponente im Central US Data Center beim Skalieren. Die Kapazitätsengpässe breiteten sich kaskadenartig aus und führten zu Auth-Fehlern, die wiederum weitere Dienste beeinträchtigten.

Copilot als Verstärker

Interessant: Copilot brauchte länger zur Wiederherstellung als andere Dienste. Fehler in Copilot-Diensten lösten eine Client-Side Retry-Loop aus, die den Traffic während der Recovery-Phase weiter erhöhte. GitHub musste dieses Verhalten erst entschärfen, bevor der Traffic sicher zurückgeführt werden konnte.

Massive Wachstumszahlen

Die Zahlen erklären den Druck: Monatliche Commits sind von 1,4 Milliarden (April) auf 2,9 Milliarden gestiegen. GitHub hat seit April 3 Millionen CPU-Cores und 120 Petabyte High-Speed-Storage hinzugefügt. Azure bedient mittlerweile 58% der Plattform-Last — von 12% im Mai. Auch die monatlichen GitHub Actions-Runs stiegen auf über 100 Millionen.

Was GitHub jetzt tut

Zwei unmittelbare Maßnahmen: Erstens konsistente Retry-Limits und -Budgets service-übergreifend, um Retry-Stürme zu verhindern. Zweitens Überprüfung niederpriorer CPU- und Memory-Alerts, um Komponenten zu identifizieren, die bei Traffic-Spitzen versagen könnten. Zusätzlich werden kritische Systeme isoliert und Shared Dependencies entfernt.