GitHubs Dienstausfälle im April 2026: Ursachen und Maßnahmen

GitHub verzeichnete im April 2026 insgesamt zehn Vorfälle, die zu Leistungseinbußen in den Kernfunktionen führten. Besonders betroffen waren die Code-Suche, Audit-Logs und der Copilot-Coding-Agent. Um die Transparenz zu erhöhen, veröffentlichte das Unternehmen Ende April einen ausführlichen Bericht zu den beiden größten Störungen am 23. und 27. April. Zudem wurden Anpassungen an der Statusseite vorgenommen, um detailliertere Informationen schneller bereitzustellen.

Code-Suche fiel für Stunden komplett aus

Am 1. April 2026 zwischen 14:40 und 17:00 UTC war die Code-Suche bei GitHub vollständig nicht verfügbar. Sämtliche Suchanfragen scheiterten während dieser Phase. Erst gegen 17:00 UTC konnte ein eingeschränkter Betrieb wiederhergestellt werden, allerdings mit veralteten Ergebnissen. Die vollständige Wiederherstellung mit aktuellen Daten dauerte bis 23:45 UTC – fast neun Stunden nach Beginn des Vorfalls.

Während der zweistündigen vollständigen Ausfallphase wurden alle 100 % der Suchanfragen fehlgeschlagen. Nach der teilweisen Wiederherstellung enthielten die Ergebnisse keine Änderungen an Repositories mehr, die nach 07:00 UTC desselben Tages vorgenommen wurden. Die vollständige Re-Indexierung dauerte bis 23:45 UTC. Der Auslöser war eine zu aggressive Automatisierung während einer geplanten Infrastrukturaktualisierung des Messagingsystems. Ein Koordinationsfehler zwischen den Diensten stoppte die Indexierung, und ein unbeabsichtigter Einsatz löschte interne Routing-Informationen. Dadurch verschlimmerte sich die Störung zu einem kompletten Ausfall.

Die Wiederherstellung erfolgte durch einen kontrollierten Neustart der Messaging-Infrastruktur und Zurücksetzen des Suchindex auf einen Zeitpunkt vor der Störung. Es gab keine Datenverluste, da der Suchindex nur eine sekundäre Darstellung der Repositories ist. GitHub plant, zukünftig schrittweise Updates mit besseren Gesundheitsprüfungen einzuführen, um Probleme frühzeitig zu erkennen. Zudem sollen Schutzmechanismen für Bereitstellungen und schnellere Wiederherstellungstools implementiert werden.

Audit-Logs für kurze Zeit nicht zugänglich

Am 1. April 2026 zwischen 15:34 und 16:02 UTC war das Audit-Log-System zeitweise nicht erreichbar. Der Grund war ein gescheiterter Anmeldeinformationswechsel für den zugrundeliegenden Datenspeicher. Während dieser 28-minütigen Phase konnten Audit-Logs weder über die API noch über die Weboberfläche abgerufen werden. Betroffen waren 4.297 API-Akteure und 127 github.com-Nutzer, die mit 5xx-Fehlern konfrontiert wurden. Ereignisse, die in diesem Zeitraum entstanden, wurden bis zu 29 Minuten verzögert verarbeitet. Kunden mit GitHub Enterprise Cloud und Datenresidenz waren nicht betroffen.

Das Team wurde sechs Minuten nach Beginn der Störung um 15:40 UTC benachrichtigt und beendete den Vorfall durch einen Neustart der betroffenen Umgebung. Die vollständige Wiederherstellung erfolgte um 16:02 UTC. Als Folge des Vorfalls wurden die Prozesse für Anmeldeinformationswechsel überarbeitet und die Überwachungskonfigurationen angepasst. Paging-Schwellenwerte wurden optimiert, um ähnliche Vorfälle schneller zu erkennen.

Copilot-Agenten durch fehlerhafte Rate-Limits blockiert

Am 9. April 2026 traten zwei separate Störungen im Copilot-Coding-Agent-Dienst auf. Zwischen 09:05 und 19:05 UTC sowie von 16:05 bis 20:36 UTC kam es zu erheblichen Verzögerungen bei der Erstellung neuer Agenten-Sitzungen. Rund 84 % der neuen Sitzungsanforderungen wurden verzögert, wobei die Wartezeiten im Extremfall auf 54 Minuten anstiegen – normalerweise liegen diese zwischen 15 und 40 Sekunden. Die Fehlerrate lag durchschnittlich bei 83,9 %, mit Spitzenwerten von 97,5 %. Etwa 22.700 Workflow-Erstellungen wurden verzögert oder scheiterten.

Verantwortlich war ein Bug in der Rate-Limit-Logik, der eine globale Begrenzung statt einer nutzerbasierten Steuerung anwandte. Ein zusätzlicher Faktor war ein plötzlicher Anstieg des API-Verkehrs durch eine Client-Aktualisierung, die den Datenverkehr an einem internen Endpunkt um das Drei- bis Vierfache erhöhte. Im zweiten Vorfall führte ein interner Dienst das Rate-Limit erneut aus, kombiniert mit einem Caching-Fehler, der den begrenzten Zustand über das eigentliche Zeitfenster hinaus beibehielt.

Das Team erkannte den Vorfall innerhalb von 15 Minuten und deaktivierte den fehlerhaften Caching-Mechanismus per Feature-Flag. Zudem wurden die API-Aufrufe auf installationsspezifische Anmeldeinformationen umgestellt, um die Rate-Limits korrekt zu steuern. Die vollständige Wiederherstellung erfolgte um 20:36 UTC. Alle während des Vorfalls angehaltenen Jobs wurden nach der Wiederherstellung verarbeitet.

GitHub hat seitdem automatisierte Überwachung und Warnmeldungen eingeführt, um solche Ausfälle proaktiv zu erkennen. Zudem wurden Verbesserungen an der Caching-Logik vorgenommen, um unnötigen API-Verkehr zu reduzieren. Weitere Arbeiten sollen helfen, die Rate-Limit-Steuerung noch granularer zu gestalten.

GitHub Pages mit erhöhten Fehlerraten

Am 13. April 2026 zwischen 18:53 und 20:30 UTC kam es zu erhöhten Fehlerraten bei GitHub Pages. Im Durchschnitt lagen die Fehler bei 10,58 %, mit Spitzenwerten von 12,77 %. Die genaue Ursache und die Maßnahmen zur Behebung wurden nicht im Detail veröffentlicht.

GitHub betont, dass die Stabilität der Plattform eine Priorität bleibt und kontinuierlich in Infrastruktur, Überwachung und Prozesse investiert wird. Die kürzlichen Vorfälle haben gezeigt, wie wichtig robuste Mechanismen zur Fehlererkennung und -behebung sind – sowohl für die interne als auch für die externe Dienstqualität.