GitHub-Dienste fast acht Stunden beeinträchtigt
Ein Konfigurationsfehler beim Autoscaling und ein unentdeckter Fehler in Visual Studio Code haben am 17. August einen langen GitHub-Ausfall ausgelöst. Von 13:28 UTC bis 21:15 UTC verzeichneten Issues, Pull Requests, APIs, GitHub Actions und GitHub Copilot erhöhte Fehlerraten.
Für Entwicklungsabteilungen waren damit mehrere zentrale Arbeitsschritte gleichzeitig betroffen. Pull Requests und Code-Reviews konnten ins Stocken geraten, während GitHub Actions als Plattform für CI/CD, also automatisierte Tests und Softwarebereitstellung, nur eingeschränkt verfügbar war.
| Zeitpunkt | Status |
|---|---|
| 13:28 UTC | Beginn der Störung |
| 16:36 UTC | Die meisten Dienste wiederhergestellt |
| 18:03 UTC | GitHub Actions wiederhergestellt |
| 21:02 UTC | Copilot Token Service wiederhergestellt |
| 21:15 UTC | Störung vollständig behoben |
| Gesamtdauer | 7 Stunden und 47 Minuten |
Autoscaling überwachte die falsche Komponente
Die unmittelbare Ursache war eine Netzwerksättigung an Load Balancern im US-Rechenzentrum Central US. Ein Istio-Sidecar erreichte sein Nebenläufigkeitslimit. Ein Sidecar ist ein zusätzlicher Netzwerkprozess, der neben dem eigentlichen Dienst läuft und dessen Datenverkehr verarbeitet.
Das Autoscaling, also die automatische Bereitstellung zusätzlicher Kapazität, reagierte nicht. Die Richtlinie überwachte nur den Host-Dienst, nicht aber das Nebenläufigkeitslimit des Sidecars. Dadurch blieb die kritische Überlastung für die Skalierungslogik unsichtbar.
GitHub zufolge wurde das Problem durch eine zu optimistische Wiederholungslogik verschärft, die interne Load Balancer überlastete. Das Zitat ist sinngemäß aus dem Englischen übersetzt.
VS Code verstärkte den Datenverkehr um das Zehnfache
Verzögerte Antworten eines internen Endpunkts lösten zusätzlich einen bislang unentdeckten Retry-Bug in Visual Studio Code aus. Der Editor wiederholte Anfragen an den Copilot Token Service so aggressiv, dass sich der Datenverkehr ungefähr verzehnfachte. Damit wurde aus einer lokalen Überlastung eine sich selbst verstärkende Anfrageflut.
Als Notmaßnahme drosselten die GitHub-Techniker die Wiederholungsversuche am Gateway per Code-Änderung. Load Balancer wiesen Anfragen an den Copilot Token Service zeitweise mit dem Statuscode HTTP 403 zurück. Automatisierte Abrufangriffe auf Codeload-Endpunkte erschwerten die Wiederherstellung zusätzlich.
GitHub will nun die Autoscaling-Regeln korrigieren, Istio-Limits prüfen und die Grenzen für Wiederholungsversuche überarbeiten. Auch das problematische Verhalten von Visual Studio Code soll behoben werden. Welche konkrete Änderung geplant ist und wann ein entsprechendes Update verteilt wird, ist bislang nicht bestätigt.
Ein Ausfall trifft das gesamte Entwicklungsmodell
Der Vorfall ist mehr als eine gewöhnliche Plattformstörung. In einem eng integrierten SaaS-Ökosystem hängen Quellcodeverwaltung, Pull Requests, automatisierte Tests und KI-Unterstützung am selben Anbieter. Fällt ein Teil der Plattform aus, können mehrere Entwicklungsprozesse gleichzeitig blockiert werden.
Gerade bei wachsendem Einsatz von KI steigt diese Abhängigkeit. Der VS-Code-Fehler zeigt, dass auch ein Client außerhalb des unmittelbar überlasteten Dienstes die Lage massiv verschärfen kann. Ähnliche Risiken entstehen, wenn Code-Reviews zum Engpass KI-gestützter Entwicklung werden oder zentrale Automatisierungen keine belastbare Rückfallebene besitzen.
Für Unternehmen im DACH-Raum kann ein solcher Ausfall einen erheblichen Teil eines Arbeitstags erfassen. Wie viele Kunden konkret betroffen waren und ob GitHub Entschädigungen oder Service-Credits gewährt, ist nicht bekannt.
Alternativen reduzieren das Klumpenrisiko
Eine vollständige Abkehr von GitHub ist nicht für jedes Unternehmen wirtschaftlich. Sinnvoll ist jedoch eine Architektur, bei der geschäftskritische Arbeitsabläufe nicht ausschließlich von der Verfügbarkeit eines einzelnen US-Cloud-Anbieters abhängen. Dazu gehören lokale Repository-Spiegel, exportierbare Build-Konfigurationen und dokumentierte Notfallprozesse.
Self-Hosting mit GitLab, Gitea oder Forgejo kann die operative Kontrolle erhöhen. Für KI-Funktionen kommen lokal betriebene Modelle oder austauschbare Coding-Agenten infrage. Solche Lösungen verursachen eigenen Betriebsaufwand, reduzieren aber die Abhängigkeit von Plattformausfällen und einseitigen Produktentscheidungen.
Auch der Markt beginnt sich zu bewegen. Mit Cursor Origin als GitHub-Alternative entstehen neue Angebote für Code-Hosting. Ein Anbieterwechsel allein beseitigt das Risiko allerdings nicht. Entscheidend bleibt, ob Daten, Build-Prozesse und KI-Werkzeuge tatsächlich portabel sind.