GitHubs Ausfallprotokoll Mai 2026: Infrastruktur-Updates und Lessons Learned

GitHub hat im Mai 2026 eine Reihe von Infrastruktur-Updates vorgestellt, die die Plattform zuverlässiger machen sollen. Die Fortschritte bei der Azure-Migration und der Aufteilung des Monolithen in isolierte Dienste zeigen Wirkung – trotz einiger Vorfälle, die die Herausforderungen bei der Skalierung verdeutlichen.

GitHubs Infrastruktur: Fortschritte bei Skalierung und Resilienz

Die Plattform verzeichnet ein rasantes Wachstum, das maßgeblich durch KI-gestützte Entwicklungsworkflows und agentenbasierte Automatisierung angetrieben wird. Um dieser Nachfrage gerecht zu werden, hat GitHub seine Infrastruktur grundlegend modernisiert. Ein zentraler Baustein dieser Strategie ist die Migration zu Microsoft Azure, die es ermöglicht, elastische Kapazitäten flexibel bereitzustellen.

Bis Mai 2026 wurden bereits 40 % des Monolithen-Traffics über Azure abgewickelt – ein deutlicher Anstieg gegenüber den 8 % im Februar. Der Git-Traffic liegt bei 30 %, während die Replikation von Repositories eine beeindruckende Verfügbarkeit von 99 % erreicht. Innerhalb von nur vier Monaten konnte die effektive Kapazität der Plattform mehr als verdoppelt werden.

Ein weiterer Meilenstein ist die Aufteilung des primären Datenbankclusters in unabhängige Domänen. Dadurch werden Benutzerverwaltung, Authentifizierung und Autorisierung voneinander getrennt, sodass ein Problem in einem Bereich nicht mehr das gesamte System beeinträchtigen kann. Der neue Benutzerservice wurde vollständig umgestellt und bewältigt inzwischen den doppelten Traffic bei deutlich geringeren Datenbankkosten. Zudem werden stateless Authentifizierungstokens eingeführt, die pro Anfrage durchgeführte Datenbankabfragen überflüssig machen – ein Schritt, der die Last während Trafficspitzen reduziert.

GitHubs Leitprinzip bei diesen Änderungen lautet: Verfügbarkeit geht vor Kapazität, und diese wiederum vor neuen Funktionen. Das Unternehmen räumt ein, dass noch weitere Anpassungen nötig sind, zeigt sich aber zuversichtlich, dass die Plattform langfristig zuverlässiger wird.

Mai-Vorfälle: Erkenntnisse aus neun Störungen

Im Mai 2026 traten insgesamt neun Vorfälle auf, die die Leistung verschiedener GitHub-Dienste beeinträchtigten. Drei dieser Vorfälle sollen hier detaillierter betrachtet werden, da sie Einblicke in die aktuellen Herausforderungen und die eingeleiteten Verbesserungen geben.

Vorfall am 4. Mai: Datenbankengpass durch Schema-Migration

Am 4. Mai 2026 kam es zwischen 15:34 und 16:40 UTC zu einer Serviceunterbrechung, die erhöhte Latenzzeiten und eine erhöhte Fehlerquote bei Kundenanfragen verursachte. Die Gesamtausfallzeit betrug etwa eine Stunde und sechs Minuten.

Besonders betroffen war der Dienst für Pull Requests, der während der Spitzenlast als Red eingestuft wurde. Auch Issues, Actions, Webhooks und Git-Operationen zeigten erhöhte Latenzzeiten sowie intermittierende Fehler. Abhängige Dienste wie Codespaces, Pages, Packages, OAuth und GitHub Apps sowie Marketplace und Copilot waren ebenfalls in unterschiedlichem Maße beeinträchtigt. Zum Höhepunkt des Vorfalls wurden etwa 1,3 % der Anfragen mit einem 5xx-Fehler beantwortet, während der Durchschnitt über den gesamten Zeitraum bei rund 0,46 % lag.

Der Vorfall wurde durch eine routinemäßige Schema-Migration in einer stark frequentierten Datenbanktabelle ausgelöst. Obwohl die Migration zunächst problemlos verlief, führte die steigende Last während der wöchentlichen Spitzenzeit zu einer Überlastung der Datenbankverbindungen. Dies verursachte Abfragekonflikte im primären Datenbankcluster und führte zu kaskadierenden Timeouts in abhängigen Diensten.

Der Vorfall wurde innerhalb von etwa drei Minuten nach den ersten Anzeichen durch automatisierte Überwachungssysteme sowie den Bereitschaftsdienst erkannt. Nach der Identifizierung der Migration als Ursache wurde diese pausiert, und die betroffenen Dienste erholten sich kurz darauf. Die Zeit bis zur Behebung betrug etwa 33 Minuten, die vollständige Lösung folgte weitere 30 Minuten später.

Als Folge werden mehrere Verbesserungen umgesetzt: Schema-Migrationen in großen, hochfrequentierten Tabellen werden künftig stärker an Zeiten mit geringer Auslastung gebunden. Zudem wird eine dynamische Drosselung eingeführt, die die Migration an die aktuelle Clusterlast anpasst. Automatische Schaltkreise werden Migrationen unterbrechen, sobald die Latenz oder die Verbindungsauslastung der Datenbank kritische Schwellenwerte überschreitet. Parallel wird die Überwachung erweitert, um migrationsbedingte Belastungen wie Schreibraten, Sperrzeiten und Verbindungssättigung frühzeitig zu erkennen und zu melden.

Vorfälle am 5. und 6. Mai: Probleme mit GitHub Actions in der East-US-Region

Am 5. Mai 2026 kam es zwischen 13:22 und 17:05 UTC zu einer Beeinträchtigung der gehosteten Runner in der East-US-Region von GitHub Actions. Etwa 13,5 % der Standard-Runner-Aufträge scheiterten, während rund 16 % der größeren Runner mit privatem Netzwerk in der East US entweder fehlschlugen oder um mehr als fünf Minuten verzögert wurden. Auch Copilot-Codeprüfungsanfragen waren betroffen: Etwa 8.500 Anfragen wurden während des Vorfalls mit Timeouts beendet. Nutzer erhielten Fehlerkommentare in ihren Pull Requests und mussten die Prüfung erneut anfordern. Zwar wurden die meisten Anfragen automatisch an andere Regionen weitergeleitet, doch ein Teil der Routing-Anfragen blieb in der East US hängen und war damit beeinträchtigt.

Ursache war ein Skalierungsvorgang für die VM-Erstellung der gehosteten Runner. Obwohl solche Vorgänge regelmäßig durchgeführt werden, stieß die Last in diesem Fall an eine interne Rate-Limit-Grenze, als die VMs Images aus dem Speicher abzogen. Die bestehende Logik zur Zurücknahme von Anfragen wurde in diesem Fall nicht ausgelöst, da der zurückgegebene Antwortcode nicht den erwarteten Bedingungen entsprach.

Am 6. Mai 2026 folgte ein zweiter, verwandter Vorfall, der durch die zuvor durchgeführten Reparaturarbeiten ausgelöst wurde. Zwischen 07:19 und 09:44 UTC war GitHub Actions erneut beeinträchtigt, diesmal mit einer Dauer von zwei Stunden und 25 Minuten. Die genauen Ursachen und Auswirkungen werden im Bericht nicht detailliert aufgeführt, doch GitHub bestätigte einen Zusammenhang zwischen den beiden Vorfällen.

Als Reaktion auf diese Vorfälle werden die internen Rate-Limits für VM-Erstellungsvorgänge überprüft und angepasst. Zudem wird die Logik zur Zurücknahme von Anfragen überarbeitet, um solche Szenarien künftig zu vermeiden.

Langfristige Pläne: Stabilität durch Architekturänderungen

GitHubs Fokus auf die Verbesserung der Plattformzuverlässigkeit bleibt ungebrochen. Die laufenden Projekte zur Infrastrukturmodernisierung – insbesondere die Migration zu Azure und die Aufteilung des Monolithen – sollen die Grundlage für eine stabilere und skalierbarere Plattform legen. Die jüngsten Vorfälle zeigen zwar, dass noch Herausforderungen bestehen, doch die eingeleiteten Maßnahmen zielen darauf ab, solche Störungen künftig zu minimieren.

Mit der schrittweisen Einführung stateless Authentifizierung und der Isolierung kritischer Dienste setzt GitHub auf architektonische Lösungen, die nicht nur die aktuelle Last bewältigen, sondern auch das Wachstum der nächsten Jahre unterstützen. Die kommenden Monate werden zeigen, wie sich diese Änderungen auf die Nutzererfahrung auswirken und ob die Plattform ihre Ziele in puncto Verfügbarkeit erreicht.

Für Entwickler und Unternehmen, die auf GitHub als zentrale Entwicklungsplattform setzen, bleibt die Entwicklung daher spannend – und die Fortschritte bei der Infrastruktur ein entscheidender Faktor für den Erfolg.