Zusammenfassung

  • GitHub beziffert die Störung vom 17. August auf 7 Stunden und 47 Minuten. Web- und API-Fehler erreichten etwa 20 Prozent, Downloads von Archiven und Rohinhalten rund 50 Prozent. Betroffen waren unter anderem Issues, Pull Requests, Actions, Unternehmensidentität und Copilot.
  • Ein Istio-Sidecar erreichte sein Nebenläufigkeitslimit, ohne passend zu skalieren. Danach schöpften vier HAProxy-Knoten ihre Flow-Grenzen aus. Wiederholungen steigerten den Verkehr des Copilot Token Service von üblichen 7.000–9.000 auf 70.000–100.000 Anfragen pro Sekunde.

Northern Virginia konnte einen Teil des in Central US scheiternden Verkehrs übernehmen. Dennoch blieb die Wiederherstellung unvollständig, weil verspätete Antworten neue Anfragen erzeugten.

Im detaillierten Abschluss zu Incident zkxwbgr0cnmx setzt GitHub den Zeitraum auf den 17. August von 13:28 bis 21:15 UTC. Issues, Pull Requests, APIs, Actions und Copilot verzeichneten Fehler oder erhöhte Latenz. Bei Web und API lag die Fehlerrate in der Spitze bei ungefähr 20 Prozent, bei Archiv- und Raw-Content-Downloads bei ungefähr 50 Prozent.

Auch betriebliche Kontrollflächen waren betroffen. GitHub nennt SAML- und OIDC-Authentifizierung, SCIM und Team Sync. Actions-Workflows in GitHub Enterprise Cloud mit Datenresidenz litten ebenfalls, wenn sie öffentliche, auf GitHub.com gehostete Schrittdefinitionen benötigten. Daraus folgt weder ein Datenverlust noch eine Verletzung der gewählten Speicherregion. Belegt ist eine Laufzeitabhängigkeit über mehrere Produktoberflächen hinweg.

Als unmittelbare Ursache beschreibt GitHub eine Netzwerksättigung an Load Balancern im Rechenzentrum Central US während eines neuen Lastspitzenwerts. Ein Istio-Sidecar-Pod stieß an sein Nebenläufigkeitslimit. Die Autoscaling-Regel beobachtete den Host-Service, nicht jedoch die Begrenzung des Sidecars. Am tatsächlichen Engpass kam deshalb keine zusätzliche Kapazität an.

Die Einschränkung weitete sich aus, bis vier HAProxy-Knoten ihre Flow-Limits erschöpften. Der gemeinsame Gateway-Pfad für Authentifizierung verlor Durchsatz; Anmeldelatenz und Fehler griffen auf mehrere Dienste über. Laut GitHub führte das gleichzeitige Pausieren von HAProxy auf diesen Knoten sofort zu einer breiten Erholung.

Ein Teil des fehlerhaften Verkehrs wurde nach Northern Virginia verlagert und dort erfolgreich bedient, während Central US untersucht wurde. Die meisten Dienste waren gegen 16:36 UTC wiederhergestellt. Actions blieb bis etwa 18:03 beeinträchtigt.

Bei Copilot verlängerte sich die Störung durch Rückkopplung. Verzögerte Antworten eines einzelnen internen Endpunkts lösten einen bis dahin verborgenen Retry-Fehler in VS Code aus. Eine fehlgeschlagene Token-Operation konnte mehrere weitere Anfragen auslösen und in eine Schleife geraten. Der Copilot Token Service stieg von normalerweise 7.000–9.000 auf 70.000–100.000 Requests pro Sekunde.

Die Wiederherstellung erforderte deshalb eine Begrenzung der Verstärkung. GitHub reduzierte vorübergehend Gateway-Retries, beantwortete bestimmte eingehende Copilot-Token-Anfragen an den Load Balancern mit HTTP 403 und ließ den Verkehr anschließend Standort für Standort wieder anlaufen. Der Token Service war gegen 21:02 vollständig zurück; um 21:15 wurde der Incident geschlossen.

Mehrere Scraping-Angriffe auf codeload-Endpunkte erschwerten die Reaktion. GitHub beziffert ihren Anteil an Sättigung und Dauer nicht und nennt sie nicht als ursprünglichen Auslöser. Die veröffentlichte Hauptkette reicht vom Sidecar-Limit über die unvollständige Scaling-Regel und ausgeschöpfte HAProxy-Flows bis zur Retry-Verstärkung.

Die Produktdokumentation macht die Abhängigkeiten sichtbar. Wiederverwendbare Workflow-Konfigurationen können Definitionen aus öffentlichen Repositories aufrufen. Die Referenz für GitHub-gehostete Runner nennt GitHub.com, die API, Actions-Domains und codeload.github.com als notwendige Ziele für Ausführung und Action-Downloads.

Identität ist ebenfalls ein zentraler Pfad. GitHub dokumentiert SAML SSO und SCIM als Steuerung für Unternehmenszugang und Kontenlebenszyklen. Die Beschreibung von Enterprise Cloud mit Datenresidenz nennt dedizierte GHE.com-Subdomains und regionale Speicheroptionen. Wo Daten liegen und welche Dienste eine Anmeldung oder Workflow-Ausführung benötigt, sind getrennte Fragen.

GitHubs Maßnahmenliste umfasst Sidecar-bewusstes Autoscaling, eine Prüfung der Istio-Grenzen, die Überarbeitung von Retry und Backoff in Gateways und Clients, eine Korrektur des VS-Code-Verhaltens sowie bessere Kapazitätsüberwachung und regionale Failover-Sicherungen. Das sind angekündigte Vorhaben. Ihre Umsetzung und Wirkung sind noch nicht öffentlich belegt.

Kunden können die eigene Erholung nach Pfaden prüfen: Repository-Zugriff, API, SSO, Teamänderung, Download einer öffentlichen Workflow-Definition, Runner-Start und Copilot-Token. Eine wieder erreichbare Weboberfläche beweist nicht, dass diese Funktionen gleichzeitig zurückgekehrt sind.

GitHubs REST-API-Empfehlungen verlangen, Retry-After und Rate-Limit-Reset zu beachten und die Wartezeit nach wiederholten Fehlern zu erhöhen. Das Dokument richtet sich an externe Integrationen und erklärt nicht den internen Incident. Es beschreibt jedoch dieselbe Betriebsgrenze: Unbeschränkte Wiederholungen machen aus Wartezeit zusätzliche Last.

Quellen