GitHubs Ausfall: Die doppelte Commit-Last

Sieben Stunden Siebenundvierzig Minuten, Zurückgeführt Auf Einen Überlasteten Proxy

GitHubs eigener Bericht, veröffentlicht im firmeneigenen Engineering-Blog unter dem Titel 'The August 17 outage, and the work ahead', führt den Ausfall auf einen Istio-Sidecar-Proxy im Rechenzentrum Central US zurück, der sein maximales Nebenläufigkeitslimit erreichte. Die Autoscaling-Richtlinie, die diese Kapazität überwachte, bewertete nur den Anwendungsdienst selbst, nicht den Verbindungs- und Nebenläufigkeitszustand der davorliegenden Sidecars, sodass nichts hochskalierte, als die Sidecars an ihre Grenze stießen. Als diese Proxys gesättigt waren, verlagerten sich Anfragen auf andere Knoten, die daraufhin ebenfalls an ihre eigenen Kapazitätsgrenzen stießen, und GitHubs automatische Wiederholungslogik verschärfte die Spirale, indem sie neue Anfragen an bereits überlastete Load-Balancer sendete. Ein separater Wiederholungsfehler, laut The Register in einer VS-Code-Erweiterung für die GitHub-Copilot-Authentifizierung, verschärfte den Ausfall zusätzlich: Er forderte ununterbrochen neue Authentifizierungstoken an und trieb GitHubs Token-Ausgabedienst von einer normalen Grundlast von 7.000 bis 9.000 Anfragen pro Sekunde auf 70.000 bis 100.000 Anfragen pro Sekunde, etwa das Zehnfache der üblichen Last.

Die Zahlen Hinter Einem Schlechten Nachmittag

Der Ausfall dauerte vom 17. August 2026, 13:28 bis 21:15 UTC, und GitHubs eigene Statusmeldungen bezifferten die Spitzenfehlerraten auf rund 20 Prozent bei Web- und API-Verkehr und etwa 50 Prozent bei Archiv- und Rohinhalts-Downloads, also genau der Art von Anfrage, auf die eine Build-Pipeline oder ein Abhängigkeits-Abruf angewiesen ist. Issues, Pull Requests, APIs, Actions und Copilot waren allesamt beeinträchtigt, ebenso SAML- und OIDC-Authentifizierung, SCIM und Team Sync; die meisten Dienste erholten sich bis 16:36 UTC, Actions bis 18:03 UTC, und der Copilot-Token-Dienst zuletzt, um 21:02 UTC. GitHub stellte ausdrücklich klar, dass weder dieser Vorfall noch der kleinere Actions-Ausfall am 6. August durch eine Code- oder Konfigurationsänderung verursacht wurde; beide waren, in den eigenen Worten des Unternehmens, im Kern Kapazitätsausfälle, das System hatte also keinen Spielraum mehr, statt an einem verschickten Fehler zu scheitern.

Das Commit-Volumen Hat Sich In Vier Monaten Fast Verdoppelt

In demselben Bericht verborgen liegt die Zahl, die aus dieser Geschichte über einen Ausfall eine Geschichte über Infrastruktur macht: GitHub gibt an, dass das monatliche Commit-Volumen seit April 2026 von 1,4 Milliarden auf 2,9 Milliarden gestiegen ist, in etwa vier Monaten also fast verdoppelt, begleitet von Diagrammen, die zusammengeführte Pull Requests auf rund 130 Millionen im Monat und neue Repositorys auf rund 24 Millionen im Monat zusteuern zeigen. GitHub hatte den Treiber bereits in seinem Verfügbarkeitsbericht vom Mai 2026 benannt, wo das Unternehmen einräumte, dass KI-gestütztes Programmieren und agentische Workflows die Infrastruktur zusätzlich belasten, und Microsoft hat öffentlich erklärt, dass KI inzwischen bis zu 30 Prozent des Codes in einigen eigenen Repositorys schreibt, vorbehaltlich menschlicher Prüfung. Eine Plattform, die für eine Welt ausgelegt wurde, in der Commits im Tempo menschlichen Tippens eintreffen, absorbiert nun ein Lastmuster, das von Coding-Agenten vorgegeben wird, die fortlaufend schreiben, verzweigen und pushen, und GitHubs bisherige Antwort bestand darin, Kapazität hinzuzufügen: mehr als 3 Millionen CPU-Kerne und 120 Petabyte Hochgeschwindigkeitsspeicher, wobei Azure inzwischen rund 58 Prozent der Plattformlast trägt, gegenüber 12 Prozent im Mai.

GitHub Actions Verzeichnete Dreizehn Vorfälle In Siebzehn Tagen

Tech Times berichtete nach Auswertung von GitHubs Vorfallhistorie und Statusdaten, dass GitHub Actions allein 13 einzelne Vorfälle in siebzehn Tagen in diesem August verzeichnete und dass die 90-Tage-Verfügbarkeit von 99,39 Prozent vor dem Ausfall am 17. August auf 99,33 Prozent danach zurückfiel, ein Rückgang von rund 13 Stunden angesammelter Ausfallzeit in drei Monaten auf etwa 14,5 Stunden. Das Medium stellte den Vorfall vom 17. August so dar, dass er nahezu ein ganzes Jahresbudget an zulässiger Ausfallzeit gegenüber einem Drei-Neunen-Ziel für sich allein aufgebraucht habe. GitHubs eigener Bericht zählt anders und bezeichnet den 17. August als seinen zweiten bedeutenden Vorfall des Monats nach dem Actions-Ausfall am 6. August, was eine faire Zählung großer, plattformweiter Ausfälle ist, aber nichts über die kleineren, häufigeren Actions-Störungen darunter aussagt. Beide Zählungen können gleichzeitig zutreffen, und zusammen beschreiben sie ein zweistufiges Zuverlässigkeitsproblem: Der Kern-Git-Dienst hält sich besser als die darübergelagerte CI/CD-Pipeline, und genau diese Pipeline trägt die meiste neue Last durch KI-gestützte Entwicklung.

Eine Plattform, Jede Pipeline: Das Konzentrationsrisiko

Für ein Unternehmen, das seinen gesamten Entwicklungsworkflow über GitHub abwickelt, also Versionskontrolle, CI über Actions, seine Paketregistry und Copilot zur Codegenerierung, ist nichts davon Hintergrundrauschen; es ist ein einzelner Anbieter auf dem kritischen Pfad jeder Veröffentlichung. Ein europäisches Entwicklungsteam spürt das während des eigentlichen Ausfallfensters genauso wie ein US-Team, trägt aber eine zusätzliche Belastungsebene: vertragliche Liefertermine, SLA-Zusagen gegenüber EU-Kunden und Meldepflichten bei Vorfällen unter Rahmenwerken wie NIS2 pausieren nicht deshalb, weil der Ausfall in einem US-Rechenzentrum außerhalb der Kontrolle des Teams entstand. 'GitHub ist ausgefallen' als Hintergrundrauschen zu behandeln, ergibt keinen Sinn mehr, sobald die zugrunde liegenden Zahlen zeigen, warum es dazu kam: Infrastruktur, die für eine langsamere, menschlich getaktete Welt gebaut wurde, absorbiert ein Lastmuster, das sich in vier Monaten fast verdoppelt hat, auf einer Plattform, die nach eigenem Eingeständnis den August damit verbracht hat, zweimal dieselbe Kategorie von Kapazitätsausfall zu beheben.

Wie Redundanz In Der Praxis Aussieht

Nichts davon spricht dafür, GitHub aufzugeben, das aus guten Gründen der Standard bleibt, aber es ist ein konkretes Argument dafür, die Abhängigkeit von einem einzigen Anbieter als geplantes Risiko zu behandeln statt als nachträglichen Gedanken, der erst mitten im Ausfall entdeckt wird. Das bedeutet eine gespiegelte Kopie kritischer Repositorys auf einem zweiten Host oder einem selbst betriebenen Git-Server, eine alternative CI-Runner-Konfiguration, die Builds übernehmen kann, wenn Actions beeinträchtigt ist, statt nur dann, wenn es vollständig ausfällt, und einen lokalen oder selbst gehosteten Cache für Paketabhängigkeiten, damit ein Ausfall der Registry nicht jeden Build in der Pipeline stoppt. Keine dieser Maßnahmen muss durchgehend laufen; sie müssen existieren, gelegentlich getestet werden und gut genug dokumentiert sein, damit ein Team unter Druck beim nächsten Vorfall nicht zum ersten Mal improvisiert, während die Uhr für eine Kundenfrist weiterläuft.

Weiterlesen: Ihr Zweiter Git-Host Schaltete Sich Selbst Ein  |  Irland streicht Milliarden-Vertrag mit Microsoft