GitHub legt Details zu fünf Ausfällen offen, die Actions und Copilot im August 2026 beeinträchtigten

GitHub hat Details zu fünf Vorfällen veröffentlicht, die im August 2026 die Verfügbarkeit seiner Dienste beeinträchtigten. Dazu gehörten Ausfälle bei GitHub Actions, Verzögerungen bei den Ergebnissen des Copilot Cloud Agent sowie fehlgeschlagene Anfragen an das Modell Kimi K3. Das Unternehmen führt die Vorfälle auf das Wachstum der Plattform und geringe Kapazitätsspielräume sowie auf Fehler bei der automatischen Skalierung, den Wiederholungsrichtlinien und den Wiederherstellungsmechanismen zurück.

GitHub erklärt, in die Verbesserung der Architektur und die Migration weiterer Dienste zu Azure zu investieren, wobei zunächst die Verfügbarkeit, dann die Kapazität und anschließend die Funktionen priorisiert werden. Außerdem kündigte das Unternehmen Verbesserungen bei der Kapazitätsüberwachung, dem Warteschlangenmanagement, den Wiederholungsrichtlinien und der Ausfallsicherheit zentraler Dienste an.

Fünf Vorfälle mit unterschiedlichen Ursachen

• 6. August: Der Vorfall dauerte 10 Stunden und 42 Minuten. Eine routinemäßige Bereitstellung eines internen Dienstes in Actions führte an einem Standort zu einer vorübergehenden Kapazitätsreduzierung. Dadurch wurden die Dienste überlastet, und Fehler breiteten sich auf Caching, DNS und API-Schnittstellen aus. Anschließend verlangsamte ein Fehler im Zuweisungspfad für Aufgaben die Wiederherstellung. Ein großer Anteil der Workflows schlug fehl oder verzögerte sich, und einige Ereignisse mussten manuell neu gestartet werden.
• 17. August: Die Beeinträchtigung dauerte 7 Stunden und 35 Minuten. Ursache war, dass Load-Balancer in einem Rechenzentrum ihre Kapazitätsspitze erreichten, während eine Nebenkomponente im Servicenetzwerk trotz Erreichens ihrer Parallelitätsgrenze nicht skalierte. Dies führte zu Verzögerungen und Ausfällen im gemeinsamen Authentifizierungspfad und wirkte sich auf Issues, Pull Requests, API-Schnittstellen, Actions und Copilot aus. Zudem vervielfachte ein Fehler bei den Wiederholungsversuchen den Anfrageverkehr zu einem internen Authentifizierungspunkt.
• 20. August: Der Vorfall dauerte 9 Stunden und 54 Minuten und beeinträchtigte den Status und die Ergebnisse von Copilot-Cloud-Agent-Aufgaben bei mindestens 54 Organisationen. Eine Region des Cloud-Datenbankanbieters, in der die Aufgabenstatus gespeichert wurden, fiel aus. Die regionale Umschaltung schlug aufgrund einer Speicherkonfiguration schnell fehl, sodass sich Statusaktualisierungen anstauten. Die Aufgaben selbst gingen nicht verloren, aber die Anzeige der Ergebnisse verzögerte sich, bis die Verarbeitung wiederhergestellt und die Warteschlange geleert worden war.
• 26. August: Die Beeinträchtigung dauerte 2 Stunden und 50 Minuten. Eine Welle von Ereignissen brachte eine gemeinsam genutzte Datenbank, die bereits nahe an ihrer Grenze betrieben wurde, an die Auslastungsgrenze. Dadurch verzögerte sich der Start von Actions-Aufgaben. Abhängige Dienste wie Copilot Code Review und einige GitHub-Pages-Vorgänge waren ebenfalls betroffen. GitHub musste die eingehende Last schrittweise drosseln, da es keinen automatischen Circuit Breaker gab, der den Schutz beim Auftreten von Belastungsindikatoren aktivierte.
• 27. August: Der Vorfall dauerte 2 Stunden und 8 Minuten und betraf ausschließlich Anfragen an das Modell Kimi K3 in Copilot, da sich der externe Modellanbieter verschlechterte. Der Ausfallanteil dieser Anfragen überschritt auf dem Höhepunkt des Vorfalls die Hälfte, während die übrigen Modelle und die Einstellung „Auto“ verfügbar blieben.

Was hat sich praktisch verändert?

Die angekündigten Maßnahmen zeigen, dass GitHub die Vorfälle als Probleme der Kapazität, Isolation und Wiederherstellung behandelt und nicht lediglich als einzelne Bereitstellungsfehler. Das Unternehmen verlagerte 33 % der Actions-Jobs aus einem eingeschränkten Produktionscluster auf Reservekapazität. Dadurch sank die Auslastung des Cache-Prozessors auf dem Höhepunkt von 98 % auf 80 %, was nach eigener Einschätzung etwa drei zusätzliche Monate Spielraum schuf. Die Auslastung der aus Azure migrierten Dienste erreichte zudem einen Höchstwert von 60,4 %, die des monolithischen Systems 64,3 % und die der Git-Auslastung 54 %.

Auf Datenbankebene wurde am 11. August der erste produktive MySQL-Primary in Azure betrieben, ohne dass bei den von Kunden beobachteten Schreibvorgängen nennenswerte Auswirkungen festgestellt wurden. Am 27. August wurde dieses Vorgehen mit zwei zentralen Datenbanken wiederholt. Außerdem entfernte GitHub rund eine Million Abfragen pro Sekunde aus einer alten Datenbankreplik und reduzierte durch weitere Änderungen 120.000 Abfragen pro Sekunde sowie etwa 59.000 Sekunden verschwendete Arbeit pro Stunde.

Warum ist dieser Bericht wichtig?

Die Vorfälle zeigen, dass die alleinige Nutzung horizontaler Skalierung nicht ausreicht, wenn Dienste gemeinsame Datenbanken, Authentifizierungspfade oder eine gemeinsame Actions-Infrastruktur nutzen. Unkontrollierte Wiederholungsversuche können eine teilweise Beeinträchtigung zudem in eine größere Last verwandeln. Eine verzögerte Umschaltung zwischen Regionen kann wiederum dazu führen, dass sich Statusdaten anstauen, selbst wenn die ursprünglichen Aufgaben nicht verloren gehen. Der Azure-Plan sowie Maßnahmen zur Isolation und Lastbegrenzung befinden sich weiterhin in Umsetzung. Der Bericht belegt daher nicht, dass die Risiken beseitigt wurden, sondern zeigt, worauf GitHub seine nächsten Arbeiten konzentriert: die Migration weiterer zentraler Datenbanken, die Automatisierung des Kapazitätsmanagements und den Ausbau des Umgangs mit Ausfällen von Abhängigkeiten.