Vervierfachung in zwei Jahren: Wie KI-Programmierung GitHub Actions lahmlegte

GitHubKIInfrastrukturEntwicklungswerkzeuge

Quellen:HN + web research · HN

Spät in der Nacht des 6. August 2026 kam es bei GitHub, der weltweit größten Plattform für Softwarecode, zu einer massiven Störung. Der Automatisierungsdienst GitHub Actions fiel auf breiter Front aus: Aufgaben standen stundenlang in der Warteschlange, gestartete Tasks schlugen massenhaft fehl, der Webhosting-Dienst Pages war beeinträchtigt und selbst die Code-Review-Funktionen des KI-Assistenten Copilot arbeiteten nur noch unregelmäßig. Ein Beitrag im Entwicklerforum Hacker News sammelte innerhalb von acht Stunden 299 Punkte und 253 Kommentare. Die Entwickler setzten schnell die Hinweise zusammen: Ursache für die Überlastung der Plattform war höchstwahrscheinlich der Ansturm durch KI-generierten Code. Vom GitHub-COO Kyle Daigle veröffentlichte Zahlen zeigen, dass die wöchentliche Laufzeit von Actions von 500 Millionen Minuten im Jahr 2023 auf 1 Milliarde Minuten im Jahr 2025 anstieg und in dieser Woche mit 2,1 Milliarden Minuten einen Rekordwert erreichte – eine Vervierfachung in nur zwei Jahren.

Für Leser ohne Programmierhintergrund ein kurzer Kontext: GitHub ist die zentrale Arbeitsplattform für Softwareentwickler. Millionen von Projekten weltweit werden hier verwaltet; der Code der meisten Smartphone-Apps läuft über dieses System. Actions ist der integrierte Automatisierungsdienst – vergleichbar mit einem digitalen Verwalter für den Code. Entwickler definieren Regeln, und bei jeder Codeänderung führt der Dienst automatisch Tests, Builds und Deployments durch. Arbeiten, die manuell eine halbe Stunde dauern würden, erledigt die Maschine in wenigen Minuten.

Berichterstattung über den GitHub-Ausfall Abb.: Berichterstattung über den aktuellen GitHub-Ausfall. Quelle: The Register

Der offizielle Incident-Bericht zeichnet ein einfaches Bild: Gegen 23:00 Uhr UTC+8 am 6. August bildeten sich lange Warteschlangen, Tasks liefen in Timeouts und die Erfolgsquote fiel zeitweise auf 30 bis 40 %. Während Ingenieure den Datenverkehr drosselten und Fixes einspielten, wurden nur 15 % der Benachrichtigungen über Codeänderungen durchgelassen. Unzählige Änderungen lösten daraufhin gar keine Nachfolgeaufgaben aus. Nach acht Stunden stabilisierte sich die Erfolgsquote wieder bei 99 %, aber Copilot und Pages blieben vorübergehend instabil, und Enterprise-Datenmigrationsdienste wurden komplett ausgesetzt. Dies war kein Einzelfall: Bereits am 29. Juli gab es einen ähnlichen Actions-Ausfall. Die offizielle Statusseite verzeichnete im Juli 26 Störungen und in den ersten sechs Tagen des Augusts weitere 6. Obwohl GitHub sich im April für die Ausfallwelle entschuldigt hatte und Führungskräfte im Juni strukturelle Reformen versprachen, brach die Infrastruktur einen Monat später erneut zusammen.

GitHub-Statusseite Ausfall-Zeitleiste Abb.: Verlauf des Ausfalls auf der offiziellen GitHub-Statusseite, von der Beeinträchtigung bis zur Wiederherstellung vergingen etwa 8 Stunden. Quelle: githubstatus.com

Ein Detail im Fehlerprotokoll verdient besondere Aufmerksamkeit: “Den Runnern wurden ungültige Aufgaben zugewiesen, woraufhin sie in Wiederholungsschleifen stecken blieben.” Auf Deutsch bedeutet das: Die ausführenden Server erhielten verfallene Arbeitsaufträge, stellten nach der Ausführung fest, dass diese nutzlos waren, und forderten neue Aufträge an – nur um erneut ungültige Aufgaben zu erhalten. Je verstopfter das System wurde, desto mehr ungültige Aufträge entstanden, was die Spirale weiter anheizte. Das ist ein klassisches Muster für den Zusammenbruch von Hochlastsystemen.

Woher kommt das Volumen: KI vervielfacht die Bestellungen in der Küche

Die offiziellen Daten sind beeindruckend. Im gesamten Jahr 2025 verzeichnete GitHub insgesamt 1 Milliarde Code-Commits. Heute sind es 275 Millionen Commits pro Woche – hochgerechnet rund 14 Milliarden pro Jahr. Die Actions-Laufzeit hat sich in zwei Jahren vervierfacht. Auf alltägliche Größenordnungen heruntergebrochen: 2,1 Milliarden Minuten pro Woche bedeuten, dass zu jedem beliebigen Zeitpunkt im Durchschnitt mehr als 200.000 Server gleichzeitig auf GitHub im Auftrag von Entwicklern arbeiten. 275 Millionen Commits pro Woche entsprechen durchschnittlich 450 Commits pro Sekunde. Die Plattform muss in jeder Sekunde 450 Anfragen verarbeiten und für jeden Zugriff dynamisch Maschinen bereitstellen.

Wöchentliche Laufzeit von Actions und Entwicklungsverlauf der Commits Abb.: Die wöchentliche Actions-Laufzeit hat sich in zwei Jahren vervierfacht; die wöchentlichen Commits erreichten etwa das 14-Fache des Niveaus von 2025. Datenquelle: GitHub offiziell (COO Kyle Daigle), Grafik vom Autor

Woher stammt dieser gewaltige Zuwachs? Aus der KI-Programmierung. Moderne KI-Assistenten können selbstständig Code lesen, ändern, committen und Tests ausführen. In einer einzigen Sitzung durchlaufen sie dutzende Schleifen, wobei jeder Durchlauf eine Kette automatisierter Aufgaben auslöst. Früher hat ein Entwickler ein- oder zweimal am Tag Code übertragen; heute erledigt das die KI dutzende Male am Tag. Laut Statistiken aus der Entwickler-Community stieg die Anzahl der von KIs erstellten Pull Requests von 4 Millionen pro Monat im vergangenen September auf 17 Millionen im März dieses Jahres. Allein das Werkzeug Claude Code steuert wöchentlich 2,6 Millionen Commits bei – ein Anstieg um das 25-Fache innerhalb von sechs Monaten. Wenn menschliches Programmieren dem Aufgeben einer Bestellung entspricht, dann vervielfacht KI-Programmierung die Gesamtbestellungen in der Küche schlagartig.

Wenn die Bestellungen explodieren, die Küche aber nicht ausgebaut wird, folgt eine Kettenreaktion. Der erfahrene Systemingenieur cortesoft erklärte die Mechanik auf Hacker News prägnant: Systeme werden mit Reserven konzipiert, aber sobald die Auslastung über 90 % steigt, führt jede kleine Schwankung zur Eskalation – Aufgaben stauen sich, Timeouts treten auf, Clients wiederholen Anfragen und diese Wiederholungen erzeugen noch längere Warteschlangen. Das gleicht einer Autobahn: Bei 80 % Auslastung fließt der Verkehr problemlos, bei 95 % führt ein einziges Bremsmanöver zum Stau. Er stellte klar, dass das Hinzufügen neuer Server in einer solchen Phase kaum hilft, da der Engpass an unerwarteten Stellen entsteht.

Offiziell wird repariert, den Nutzern reicht es nicht

Die Positionen beider Seiten verdeutlichen den Konflikt. GitHub räumte Kapazitätsengpässe ein und erklärte, die Ingenieure hätten die Ursache identifiziert und arbeiteten an der Behebung. Zahlende Kunden zeigten sich jedoch verärgert: Ein Unternehmenskunde mit eigenen Servern beklagte, dass selbst seine selbst gehostete Infrastruktur einen ganzen Tag lang gelähmt war. Der Nutzer zehaeva, seit 2009 auf GitHub aktiv, fand noch deutlichere Worte: Im vergangenen Jahr sei die Verfügbarkeit von GitHub von “vier Neunen” (99,99 %) auf “eine Neun” (90 %) gefallen. Während vier Neunen weniger als eine Stunde Ausfallzeit pro Jahr erlauben, bedeutet eine Neun über 30 Tage Ausfall pro Jahr – eine Entwicklung, die er direkt mit dem Kaskadeneffekt des KI-Booms in Verbindung bringt.

In den Kommentaren wurde zudem eine Grundsatzdebatte neu aufgerollt: die Infrastruktur-Migration. Nach der Übernahme durch Microsoft verlagert GitHub seine Infrastruktur schrittweise aus eigenen Rechenzentren in die Azure-Cloud. Der Nutzer toomuchtodo erinnerte daran, dass das System in der Ära eigener Rechenzentren stabiler lief, und kritisierte, dass man anstelle einer hybriden Lösung die gesamte Last in die Cloud verlegt habe. Andere vermuteten einen zu aggressiven Zeitplan für die Migration. Dem hielt ein anderer Nutzer entgegen, dass die Übernahme durch Microsoft bereits acht Jahre zurückliege, die Beschwerden aber erst im letzten Jahr massiv zugenommen hätten – was exakt mit dem Durchbruch der KI-Programmierung zusammenfällt. Unabhängig von der Interpretation bleiben zwei Fakten bestehen: Die Ausfallhäufigkeit von GitHub ist im letzten Jahr spürbar gestiegen, und das Traffic-Wachstum ist enorm.

Effizienzrevolution im Wettlauf mit der physischen Welt

Warum ist dieses Thema auch außerhalb der Entwicklerwelt relevant? Fast jedes Update, jeder Bugfix und jede neue Funktion einer Smartphone-App durchläuft die automatisierten Pipelines von GitHub. Steht die Plattform einen Tag lang still, gerät der Veröffentlichungsrhythmus unzähliger Softwareteams weltweit aus dem Takt. Auf einer tieferen Ebene offenbart sich hier ein Wettlauf zwischen digitaler Produktionsgeschwindigkeit und physischer Realität: KI lässt die Softwareproduktion exponentiell steigen, aber der Ausbau von Servern, Bandbreiten und Rechenzentren ist ein physischer Prozess mit realen Grenzen. GitHub setzte sich im vergangenen Oktober das Ziel einer 10-fachen Kapazitätserweiterung und hob dieses im Februar auf das 30-Fache an – dennoch hinkt die Infrastruktur dem Traffic hinterher. Berichten zufolge musste Microsoft sogar vorübergehend Kapazitäten beim Konkurrenten AWS anmieten, um Engpässe bei GitHub abzufedern – ein deutliches Zeichen für die enorme Anspannung.

“Alles lässt sich automatisieren” ist das verlockendste Versprechen des KI-Zeitalters. Die Realität zeigt jedoch: Auch automatisch erzeugte Aufgaben müssen am Ende auf physische Maschinen warten. Dieser Ausfall von GitHub ist ein Warnsignal – wenn alle schneller produzieren, wird die physische Infrastruktur zur knappsten Ressource. Die Produktionsgeschwindigkeit von KI ist ein Softwareproblem, die Erweiterung der Infrastruktur ein physisches. Wenn die physische Welt nicht Schritt halten kann, gerät das Fundament unter unseren Werkzeugen ins Wanken.

Weiterführende Links:

  • GitHub Status: Actions und Pages Incident Report
  • HN Discussion (item?id=49198302)
  • The Register: Latest GitHub outage squeezes Actions, Pages to death
  • Waxell: GitHub’s AI Agent Crisis: What 9 Outages Cost
  • danilchenko.dev: GitHub’s AI Agent Problem: 17 Million PRs, Five Outages, and a Kill Switch