GitHub: Azure trägt jetzt mehr als die Hälfte
Die Plattform stand fast acht Stunden still. Seit April verdoppelten sich die Commits. In den eigenen Hallen ist der Strom ausgereizt.
Sieben Stunden und 47 Minuten ohne verlässliches GitHub. CTO Vladimir Fedorov spricht von einem Kapazitätsbruch. Die Last hat die eigene Halle überholt, Azure liegt jetzt bei rund 58 Prozent.
Das Wichtigste in Kürze
- GitHub stand fast acht Stunden still. Von 13:28 bis 21:15 Uhr UTC am 17. August. Authentifizierung, Actions, APIs, Pull Requests, Issues und Copilot waren betroffen. Es war der zweite große Vorfall im August.
- Die Last hat die eigene Halle überholt. Kein schlechter Deploy. Seit April stiegen die monatlichen Commits von 1,4 auf 2,9 Milliarden. In den eigenen Rechenzentren ist der Strom für weitere Server ausgereizt.
- Azure trägt jetzt den größeren Teil. Rund 58 Prozent der Plattformlast und die Hälfte aller Git-Operationen laufen dort, im Mai waren es 12 Prozent.
Verwandt:Cloud-Knappheit: Was Q2 für Einkäufer bedeutet / AWS Identity Center: Multi-Region sitzt jetzt im Setup
Der Peak traf Central US zuerst
Wer am 17. August ein Repository öffnen, einen Pull Request mergen oder eine Action anstoßen wollte, traf auf Timeouts. GitHub selbst datiert den Vorfall auf 13:28 bis 21:15 Uhr UTC. Sieben Stunden und 47 Minuten. Fedorov schreibt im Postmortem vom 20. August den Satz, der den Tag trägt: Wer an diesem Tag Software ausliefern wollte, den hat GitHub im Stich gelassen.
Die Statusseite nennt die unmittelbare Stelle. Ein neuer Lastpeak sättigte die Loadbalancer im Rechenzentrum Central US. Zur Spitze lagen die Fehler bei Web und API bei rund 20 Prozent. Archiv- und Rohdownloads brachen zur Hälfte weg. SAML, OIDC, SCIM und Team Sync gingen mit. Wer GitHub Enterprise Cloud mit Datenresidenz nutzt und öffentliche Workflow-Schritte von github.com bezieht, merkte den Riss auch dort.
Die meisten Dienste waren um 16:36 Uhr UTC zurück, sobald Central US wieder trug. Actions hinkte bis etwa 18:03 Uhr UTC hinterher. Der Copilot-Token-Dienst brauchte bis 21:02 Uhr UTC. Genau diese Reststrecke erklärt, warum der Tag länger wirkte als der erste Erholungspunkt.
Die Retry-Schleife hat die Erholung gestoppt
Ein Teil des Verkehrs wanderte nach Northern Virginia und lief dort. Die Recovery blieb trotzdem hängen. Verzögerte Antworten eines internen Endpunkts lösten in VS Code einen latenten Retry-Fehler aus. Der Client wiederholte Anfragen, die Last stieg um etwa das Zehnfache. GitHub musste dieses Verhalten erst dämpfen, bevor der Verkehr wieder sicher auflaufen durfte.
Der Copilot-Token-Dienst zeigt die Amplitude. Im Normalbetrieb liegen dort knapp zehntausend Anfragen pro Sekunde. In der Schleife waren es 70.000 bis 100.000. GitHub reduzierte die Retry-Logik am Gateway, blockte zeitweise Token-Anfragen mit 403 und fuhr den Verkehr Standort für Standort wieder hoch. Scraping gegen die Codeload-Endpunkte erschwerte die Restarbeit zusätzlich. Es war nicht die Ursache. Es war Ballast auf einem schon überlasteten Pfad.
Fedorov zieht daraus zwei unmittelbare Konsequenzen. Einheitliche Retry-Limits, Retry-Budgets und variable Timeouts zwischen den Diensten. Und eine Prüfung jener CPU- und Speicheralarme, die bisher zu niedrig priorisiert waren, um eine plötzliche Spitze zu sehen.
Azure trägt jetzt den größeren Teil
Seit April haben sich die monatlichen Commits von 1,4 auf 2,9 Milliarden verdoppelt. The New Stack ergänzt 130 Millionen gemergte Pull Requests und 24 Millionen neue Repositories im Monat und führt das Tempo auf Coding-Agenten zurück. GitHub selbst nennt das Wachstum als Druck, nicht als Entschuldigung.
Die Antwort auf den Druck war erst Hardware, dann Umzug. Mehr als drei Millionen Prozessorkerne, 120 Petabyte schneller Speicher, zusätzliche Netzkapazität. In den eigenen Hallen endet das am Strom: Es ist so viel verbaut, wie die verfügbare Leistung zulässt. Deshalb beschleunigt GitHub die Migration zu Azure. Rund 58 Prozent der Plattformlast und die Hälfte aller Git-Operationen laufen dort. Im Mai waren es 12 Prozent.
Das nächste Ziel ist eine Lese-Architektur, die mit der Zahl der Leser linear wächst. Der Rollout beginnt bei den größten Monorepos. Das ist die Stelle, an der eine Plattform mit Agenten-Verkehr auf Dauer stehen oder erneut knicken wird.
| Kennzahl | April / Mai | August |
|---|---|---|
| Monatliche Commits | 1,4 Milliarden | 2,9 Milliarden |
| Azure-Anteil Plattformlast | 12 Prozent (Mai) | rund 58 Prozent |
| Git-Operationen auf Azure | nicht genannt | die Hälfte |
Zwei Kennzahlen aus dem Postmortem vom 20. August. Quelle: GitHub-Blog, Vladimir Fedorov.
Sidecar-Limits entscheiden über den Ausfall
Die Status-RCA legt den ersten Riss offen. Ein Sidecar am Service Mesh stieß an seine Nebenläufigkeitsgrenze. Die Autoscaling-Regel beobachtete den Host-Dienst, nicht das Sidecar. Der Pod skalierte nicht. Die Last wanderte weiter, vier HAProxy-Knoten verloren ihre Flow-Limits, der Auth-Pfad brach. Optimistic Retries verstärkten den Innenverkehr. Als GitHub HAProxy auf diesen Knoten pausierte, kam die breite Erholung fast sofort.
Was ist ein Retry-Budget? Eine harte Obergrenze, wie oft ein Dienst oder ein Client eine fehlgeschlagene Anfrage wiederholen darf. Ohne Budget wird aus einem kurzen Ruck eine Lawine. GitHub schreibt genau das jetzt zwischen die eigenen Dienste.
Drei Stellen bleiben für jeden eigenen Stack. Erstens: Skaliert die Sidecar- oder Proxy-Schicht mit? Misst das Autoscaling nur den inneren Prozess? Zweitens: Haben Clients und Gateways ein gemeinsames Retry-Budget? Verstärkt jeder Timeout den nächsten? Drittens: Liegt Authentifizierung auf einem Pfad, den eine Region allein umwerfen kann? GitHub hat Verkehr nach Virginia geschoben. Der Token-Dienst erholte sich trotzdem zuletzt.
Fedorov nennt den Maßstab selbst. Die Entwicklergemeinschaft kann nur arbeiten, wenn GitHub trägt. Am 17. August hat es das nicht.
Häufige Fragen
Wie lange stand GitHub am 17. August still?
Von 13:28 bis 21:15 Uhr UTC, also 7 Stunden und 47 Minuten. Die meisten Dienste waren um 16:36 Uhr UTC zurück. Actions blieb bis etwa 18:03 Uhr UTC beeinträchtigt, der Copilot-Token-Dienst bis 21:02 Uhr UTC.
War ein schlechter Deploy die Ursache?
Nein. Fedorov schreibt, weder der 6. noch der 17. August seien durch eine Code- oder Konfigurationsänderung entstanden. Kern war ein Kapazitätsbruch: Kritische Komponenten skalierten nicht, bevor die Nachfrage die Kapazität überstieg.
Warum hat Azure den Ausfall nicht verhindert?
Azure trägt heute rund 58 Prozent der Plattformlast. Der Riss saß zuerst in Central US, in den eigenen Loadbalancern. Verkehr wanderte nach Northern Virginia und lief dort. Die Recovery hing danach an der Retry-Schleife, nicht daran, dass Azure fehlte.
Was hat Copilot so lange lahmgelegt?
Ein latenter Retry-Fehler in VS Code verstärkte den Verkehr um etwa das Zehnfache. Der Copilot-Token-Dienst stieg von knapp zehntausend auf 70.000 bis 100.000 Anfragen pro Sekunde. GitHub dämpfte Retries am Gateway und blockte zeitweise Token-Anfragen, bevor der Dienst um 21:02 Uhr UTC wieder stabil war.
Was bleibt aus dem Vorfall für den eigenen Betrieb?
Drei Stellen: Sidecar- und Proxy-Limits im Autoscaling mitmessen, Retry-Budgets zwischen Client und Gateway setzen, Authentifizierung nicht auf eine Region allein legen. GitHub selbst schreibt Retry-Limits und niedrig priorisierte Alarme jetzt auf die Sofortliste.
Lesetipps der Redaktion
cloudmagazinCoreWeave plant 360 MW in Indonesien ab 2028cloudmagazinSouverän bei Daten, abhängig beim KI-ModellcloudmagazinCloudflare macht HTTP 402 zur Bezahlschranke für KI-AgentenMehr aus dem MBF Media Netzwerk
MyBusinessFutureCloudflare 402: Ihr nächster Kunde ist ein KI-AgentDigital ChiefsFable 5 bleibt teuer: Firmen meiden Anthropics TopmodellSecurityTodayMicrosoft Teams: Android-Pfad lässt Angreifer-Code durchBildquelle: KI-generiert (August 2026)
