GitHub: Nicht fixierte Abhängigkeit verursacht 36.800 fehlgeschlagene Copilot Code Reviews

Unternehmen und Produkt

GitHub ist eine Plattform für Softwareentwicklung und Zusammenarbeit. Entwickler und Unternehmen nutzen sie, um Repositories zu hosten, Source Code zu verwalten, Änderungen zu prüfen, Workflows zu automatisieren und Softwareprojekte zu koordinieren.

GitHub Copilot ist der KI-gestützte Entwicklungsassistent des Unternehmens und bietet Funktionen wie Code Completion, Chat, Coding Agents und automatisierte Code Reviews.

Copilot Code Review analysiert vorgeschlagene Änderungen in Pull Requests und gibt Feedback zu potenziellen Bugs, Qualitätsproblemen und möglichen Verbesserungen. Da diese Funktion als Verarbeitungs-Workflow arbeitet, ist sie darauf angewiesen, dass mehrere Komponenten wie Job Scheduling, Runtime-Umgebungen, Software-Abhängigkeiten und Model Services reibungslos zusammenspielen. Fällt eine dieser Abhängigkeiten aus, kann dies verhindern, dass der gesamte Review abgeschlossen wird.

Was war passiert?

Der Incident begann, als der für die Verarbeitung von GitHub Copilot Code Reviews zuständige Workflow automatisch eine neu veröffentlichte Version einer Abhängigkeit übernahm. Diese Version war mit der Runtime-Umgebung des Workflows nicht kompatibel, sodass die Reviews nicht mehr korrekt verarbeitet werden konnten.

Da der Workflow so konfiguriert war, dass er automatisch die jeweils neueste verfügbare Version verwendete statt einer gezielt getesteten und fixierten Version, führte das externe Release praktisch zu einer nicht validierten automatischen Änderung in der Produktionsumgebung. Die bestehenden Validierungsprozesse verhinderten dies nicht. Sobald die neue Version ausgewählt wurde, schlugen die Copilot Code Review Jobs unmittelbar fehl.

Die Auswirkungen des Problems wurden durch das Fehlerverhalten des Systems erheblich verstärkt. Jobs, die nicht erfolgreich gestartet oder abgeschlossen werden konnten, wurden nicht sofort beendet. Stattdessen blieben sie aktiv, bis sie ihr konfiguriertes Timeout erreichten.

Dadurch wurde die Wiederherstellung zu einem zweistufigen Prozess: Zunächst musste GitHub verhindern, dass neue Reviews weiterhin die fehlerhafte Abhängigkeit verwendeten. Anschließend musste das Unternehmen warten, bis Tausende bereits gestartete Jobs ihr Timeout erreichten und aus den Verarbeitungswarteschlangen entfernt wurden. Neue Review-Anfragen funktionierten daher bereits wieder, während die Bereinigung im Backend noch andauerte.

Timeline

• 17:30 UTC: Die Auswirkungen für Nutzer beginnen. Bei über GitHub.com eingereichten GitHub Copilot Code Review-Anfragen kommt es zunehmend zu Fehlern.
• Während des Incidents: Bei betroffenen Pull Requests wird die Meldung „Copilot ran into an error“ angezeigt. Die durchschnittliche Fehlerrate liegt bei 81,6 % und erreicht in der Spitze 93,9 %.
• Während der Untersuchung: Die Engineers von GitHub identifizieren eine neu veröffentlichte Abhängigkeit, die vom Workflow zur Verarbeitung der Code Reviews verwendet wird, als Ursache. Sie stellen fest, dass diese mit der Runtime-Umgebung des Workflows nicht kompatibel ist.
• Während der Fehlerbehebung: Die Engineers entfernen die problematische Version der Abhängigkeit und stellen den betroffenen Verarbeitungsservice erneut bereit.
• 18:44 UTC: Neu angeforderte Copilot Code Reviews funktionieren zunehmend wieder.
• 18:55 UTC: Die Fehlerrate bei Code Reviews kehrt auf das normale Niveau zurück. Damit enden die Auswirkungen für Nutzer.
• 19:59 UTC: Die verbleibenden Review-Jobs, die noch auf ihr Timeout gewartet hatten, sind vollständig abgearbeitet und aus dem Verarbeitungssystem entfernt.
  
  

Time to Detect (TTD): Nicht öffentlich bekannt gegeben.
Time to Resolve (TTR): 1 Stunde und 25 Minuten für die Auswirkungen auf Nutzer, von 17:30 bis 18:55 UTC. Bis die Backend-Warteschlangen vollständig abgearbeitet sind, vergehen 2 Stunden und 29 Minuten.

Wer war betroffen?

• Nutzer, die GitHub Copilot Code Reviews über GitHub.com anforderten.
• Rund 36.800 Code-Review-Anfragen schlugen fehl.
• Nutzer, die auf automatische Copilot Reviews angewiesen waren, erhielten keine oder nur verzögerte Reviews.
• GitHub Enterprise Cloud mit Data Residency war nicht betroffen.
• Die Störung war ausschließlich auf Copilot Code Review beschränkt. Die GitHub-Kernfunktionen und andere Copilot-Services blieben vollständig verfügbar.

Wie reagierte GitHub?

Nachdem die GitHub-Engineers die erhöhte Fehlerrate auf die inkompatible Version der Abhängigkeit zurückgeführt hatten, entfernten sie das problematische Release und stellten den betroffenen Verarbeitungsservice erneut bereit. Dadurch wurden neue Reviews erfolgreich von dem inkompatiblen Code isoliert und die Verfügbarkeit für Nutzer war bis 18:55 UTC wiederhergestellt. Bereits zuvor gestartete Jobs liefen weiter, bis ihre Timeouts abgelaufen waren. Bis 19:59 UTC waren sie vollständig abgearbeitet.

Um solche Incidents zukünftig zu vermeiden, kündigte GitHub mehrere grundlegende Verbesserungen an:

• Fixierung der Abhängigkeit auf eine nachweislich kompatible Version, anstatt automatisch das jeweils neueste Release zu übernehmen.
• Einführung von Kompatibilitätsprüfungen für alle zukünftigen Versionen der Abhängigkeit.
• Verbesserung des Fail-Fast-Verhaltens, wenn der Review-Prozessor nicht gestartet werden kann.
• Einführung kürzerer Timeout-Limits für Review-Workflows, um eine unnötige Belegung von Verarbeitungskapazitäten zu verhindern.
• Verbesserung des Monitorings speziell für Fehler beim Abschluss von Code Reviews.

Wie kommunizierte GitHub?

GitHub dokumentierte den Incident in seinem offiziellen Verfügbarkeitsbericht für Juni 2026. Die Kommunikation war transparent und enthielt konkrete Angaben zur Dauer des Incidents, zu den Fehlerraten, zur Anzahl der fehlgeschlagenen Anfragen und zur technischen Ursache.

Bemerkenswert ist, dass GitHub klar zwischen der Wiederherstellung der Verfügbarkeit für Kunden um 18:55 UTC und der vollständigen Wiederherstellung im Backend um 19:59 UTC unterschied. Dadurch erhielten Kunden ein präzises und technisch detailliertes Bild vom Verlauf des Incidents, anstatt sich auf einen einzigen, potenziell irreführenden „Resolved“-Zeitstempel verlassen zu müssen.

Wichtigste Erkenntnisse für andere Teams

• Produktionsabhängigkeiten fixieren: Automatisch die jeweils neueste Version einer Abhängigkeit zu übernehmen, macht aus einem externen Release praktisch ein unkontrolliertes Production Deployment. Verwenden Sie deshalb immer getestete und fixierte Versionen.
• Dependency-Updates wie Deployments behandeln: Alle Änderungen an Abhängigkeiten sollten Tests, stufenweise Rollouts und Monitoring durchlaufen, bevor sie die Produktionsumgebung erreichen.
• Runtime-Kompatibilität validieren: Eine Abhängigkeit kann sich erfolgreich installieren lassen und dennoch in der tatsächlichen Produktions-Runtime fehlschlagen. Tests müssen sicherstellen, dass der vollständige Workflow erfolgreich startet und abgeschlossen wird.
• Bei Startfehlern Fail Fast anwenden: Ein Verarbeitungsjob, der nicht korrekt initialisiert werden kann, sollte sofort beendet werden. Fehlgeschlagene Jobs bis zu einem langen Timeout aktiv zu lassen, verschwendet Ressourcen und verlangsamt die Wiederherstellung.
• Kürzere, phasenspezifische Timeouts festlegen: Ein einziges langes Timeout für einen gesamten Workflow verzögert die Fehlererkennung. Unterschiedliche Verarbeitungsschritte benötigen realistische, spezifische Timeout-Limits.
• Erfolgreiche Ergebnisse überwachen: Infrastrukturmetriken allein zeigen nicht, ob Nutzer tatsächlich Ergebnisse erhalten. Überwachen Sie das Verhältnis zwischen angeforderten, gestarteten, abgeschlossenen und fehlgeschlagenen Jobs.
• Service-Wiederherstellung und Queue-Wiederherstellung getrennt betrachten: Erfassen und kommunizieren Sie die Wiederherstellung für Nutzer immer unabhängig davon, wann der Backlog vollständig abgearbeitet ist.

Zusammenfassung

Am 4. Juni 2026 kam es bei GitHub Copilot Code Review zu einem massiven Anstieg der Fehlerrate. Rund 36.800 Review-Anfragen waren betroffen, in der Spitze lag die Fehlerrate bei 93,9 %. Ursache des Incidents war eine nicht fixierte Software-Abhängigkeit, die automatisch auf eine Version aktualisiert wurde, die mit der Runtime-Umgebung des Workflows nicht kompatibel war. Fehlgeschlagene Jobs wurden nicht sofort beendet, sondern blieben bis zum Timeout aktiv. Dadurch belegten sie Verarbeitungskapazitäten und verzögerten den vollständigen Abbau der Warteschlangen. GitHub entfernte die inkompatible Version der Abhängigkeit und stellte den betroffenen Service erneut bereit. Die Verfügbarkeit für Nutzer war nach 1 Stunde und 25 Minuten wiederhergestellt, während es insgesamt 2 Stunden und 29 Minuten dauerte, bis die verbleibenden Backend-Workloads vollständig abgearbeitet waren. Der Incident zeigte, dass jede nicht fixierte Abhängigkeit zu einer externen Production-Deployment-Pipeline werden kann, über die ein Team nicht die vollständige Kontrolle hat.

So kann ilert helfen

Wenn ein Problem mit einer Abhängigkeit dazu führt, dass automatisierte Jobs unbemerkt fehlschlagen, müssen Teams den Rückgang erfolgreicher Ergebnisse für Nutzer schnell erkennen, ohne von einer Alarmflut überwältigt zu werden.

• Alarmierung bei fehlgeschlagenen Reviews: Leiten Sie kritische Metriken wie Abschlussraten, Queue-Tiefe und Verarbeitungslatenz direkt an die zuverlässigen und handlungsorientierten Alarmierungsfunktionen von ilert weiter. So lassen sich Einbrüche bei den Ergebnissen erkennen, selbst wenn die Infrastruktur auf den ersten Blick fehlerfrei erscheint.
• Eskalation an die zuständigen Teams: Nutzen Sie das Bereitschaftsmanagement und die Eskalationsrichtlinien von ilert, um gezielt Plattform-, Runtime- und Dependency-Management-Teams sofort zu benachrichtigen, sobald definierte Schwellenwerte überschritten werden.
• Doppelte Benachrichtigungen reduzieren: Die Deduplizierung und Gruppierung von Alarmierungen in ilert verhindert, dass Tausende fehlgeschlagene Jobs Tausende einzelne Benachrichtigungen auslösen. So können sich die zuständigen Teams auf die Fehlerbehebung konzentrieren.
• Rollback koordinieren: Nutzen Sie dedizierte Incident Channels, damit Entwickler und Incident Commander Tests, erneute Deployments und Monitoring in Echtzeit koordinieren können.
• Eingeschränkte Funktionalität kommunizieren: Nutzen Sie ilert Statusseiten, um Einschränkungen wie fehlgeschlagene Copilot Code Reviews sofort zu kommunizieren und Nutzer gleichzeitig darüber zu informieren, dass die übrige Plattform weiterhin verfügbar ist.