CircleCI: Probleme beim Netzwerk-Routing beeinträchtigen macOS-Jobs

Unternehmen und Produkt

CircleCI ist eine Plattform für Continuous Integration und Continuous Delivery, mit der Softwareteams Build-, Test- und Deployment-Workflows automatisieren.

Für macOS-Jobs greift CircleCI auf einen externen Mac-Infrastrukturanbieter zurück. Diese Umgebungen unterstützen Teams bei der Entwicklung und beim Testen von Software für Apple-Plattformen. Sie benötigen dafür einen zuverlässigen Zugriff auf externe Dienste wie GitHub. Bei diesem Incident lag die Ursache weder in der CircleCI-Kernplattform noch direkt bei GitHub, sondern auf dem Netzwerkpfad zwischen dem Mac-Infrastrukturanbieter und GitHub.

Was war passiert?

Beginnend am 13. Juli 2026 um 18:00 Uhr UTC blieben Jobs auf der macOS-Flotte von CircleCI bei GitHub-Fetches hängen. Normalerweise dauern diese Abrufe ein bis zwei Minuten. Während des Incidents dauerten sie jedoch 20 bis 30 Minuten und führten häufig zu Job-Timeouts.

Als Ursache wurde ein Kapazitäts- und Routing-Problem auf bestimmten Netzwerkpfaden zwischen dem Mac-Infrastrukturanbieter von CircleCI und GitHub identifiziert. macOS-Jobs von CirceCI werden bei einem externen Mac-Infrastrukturanbieter ausgeführt, der über mehrere vorgelagerte Netzwerkpfade mit dem Internet verbunden ist. Als einige dieser Pfade von Kapazitätsengpässen oder Routing-Problemen betroffen waren, verlangsamte sich der Abruf von Code oder Abhängigkeiten aus GitHub oder kam vollständig zum Stillstand.

Der Incident trat sporadisch auf. Nach dem ersten Auftreten schien sich die Situation zu stabilisieren, nachdem der Traffic umgeleitet worden war. Später am selben Tag trat das Problem jedoch wieder auf, ebenso am 14. Juli. CircleCI bestätigte später, dass das bestehende automatisierte Monitoring den Incident nicht erkannt hatte. Dadurch wurde eine Lücke im End-to-End-Monitoring der GitHub-Fetch-Performance auf der macOS-Flotte sichtbar.

Die wichtigste Erkenntnis: Der Fehler lag nicht eindeutig bei einer einzelnen Plattform, sondern an der Schnittstelle zwischen mehreren Anbietern. Dadurch war er schwerer zu erkennen, zu reproduzieren und dauerhaft zu beheben.

Timeline

• 24. Juni, 20:18 Uhr UTC, bis 25. Juni, 03:09 Uhr UTC: Bei CircleCI tritt ein ähnlicher Incident auf, der die Verbindung von macOS-Jobs zu GitHub beeinträchtigt . Der Incident wurde durch ein Netzwerk-Routing-Problem unter Beteiligung des Mac-Infrastrukturanbieters verursacht.
• 13. Juli, 18:00 Uhr UTC: Bei einigen Kunden kommt es beim Abrufen von Code und Abhängigkeiten aus GitHub zu sporadischen Fehlern und Verzögerungen in macOS-Jobs.
• 13. Juli, 18:55 Uhr UTC: CircleCI leitet eine Untersuchung ein und informiert seine Kunden über die Statusseite.
• 13. Juli, 19:04 Uhr UTC: Der Mac-Infrastrukturanbieter stellt eine erhöhte Latenz auf einem Netzwerkpfad fest und leitet den Traffic über eine alternative Route um.
• 13. Juli, 19:40 Uhr UTC: CircleCI markiert das erste Auftreten des Problems als behoben.
• 13. Juli, 20:44 Uhr UTC: Kunden melden ein erneutes Auftreten des Problems.
• 13. Juli, 21:52 Uhr UTC: CircleCI öffnet den Incident erneut und setzt den Status auf der Statusseite zurück auf „Untersuchung läuft“.
• 13. Juli, 23:35 Uhr UTC: CircleCI veröffentlicht einen Workaround und empfiehlt Kunden, den Wert für no_output_timeout auf 15 bis 20 Minuten zu erhöhen. Anschließend wird der Incident in die Monitoring-Phase verschoben.
• 14. Juli, 13:59 Uhr UTC: CircleCI bestätigt, dass bei Kunden weiterhin sporadische Fehler auftreten und setzt den Status erneut auf „Untersuchung läuft“.
• 14. Juli, 15:35 Uhr UTC: CircleCI informiert seine Kunden darüber, dass der Infrastrukturanbieter Änderungen an der Netzwerkkonfiguration testet, um die Ursache des Problems einzugrenzen.
• 14. Juli, 16:31 Uhr UTC: CircleCI berichtet, dass eine verringerte eingehende Bandbreite auf einer bestimmten Route die Abrufzeiten von Repositorys beeinträchtigt.
• 14. Juli, 16:36 Uhr UTC: Der Mac-Infrastrukturanbieter identifiziert die betroffenen Netzwerkpfade und leitet den Traffic von ihnen weg.
• 14. Juli, 16:58 Uhr UTC: Die Abrufzeiten normalisieren sich, und CircleCI verschiebt den Incident in die Monitoring-Phase.
• 14. Juli, 20:18 Uhr UTC: Bei einigen Kunden treten erneut lange Abrufzeiten auf. CircleCI setzt den Status auf der Statusseite wieder auf „Untersuchung läuft“.
• 14. Juli, 22:07 Uhr UTC: Der Anbieter identifiziert zwei weitere beeinträchtigte Netzwerkpfade und leitet den Traffic von ihnen weg.
• 14. Juli, 23:18 Uhr UTC: Die Abrufzeiten stabilisieren sich, und CircleCI markiert den Incident als behoben.

Time to Detect (TTD): Nicht öffentlich bekannt. Die Beeinträchtigungen für Kunden begannen um 18:00 Uhr UTC, CircleCI leitete die öffentliche Untersuchung um 18:55 Uhr UTC ein. Später erklärte CircleCI, dass das bestehende automatisierte Monitoring den Incident nicht erkannt hatte.

Time to Resolve (TTR): Etwa 29 Stunden und 18 Minuten vom Beginn der Probleme bei den Kunden bis zur endgültigen Behebung. Innerhalb dieses Zeitraums traten die Probleme sporadisch auf.

Wer war betroffen?

Der Incident betraf einige Kunden, die Jobs auf der macOS-Flotte von CircleCI ausführten – insbesondere Workflows, die Code, Repositorys oder Abhängigkeiten aus GitHub abrufen mussten.

Die betroffenen Jobs blieben während der GitHub-Fetch-Schritte hängen oder liefen nicht weiter. Abrufe, die normalerweise ein bis zwei Minuten dauerten, verlängerten sich bei einigen Kunden auf 20 bis 30 Minuten und führten häufig zu Timeouts.

Wie reagierte CircleCI?

CircleCI leitete eine Untersuchung ein, informierte seine Kunden über seine Statusseite und arbeitete direkt mit dem externen Mac-Infrastrukturanbieter zusammen, um beeinträchtigte Netzwerkpfade zu identifizieren und den Traffic von ihnen wegzuleiten.

Nachdem das Problem erneut aufgetreten war, öffnete CircleCI den Incident wieder und sammelte gemeinsam mit dem Anbieter Diagnosedaten. Das Team veröffentlichte außerdem einen Workaround und empfahl betroffenen Kunden, no_output_timeout auf 15 bis 20 Minuten zu erhöhen. Dadurch erhielten langsame GitHub-Fetches mehr Zeit für den Abschluss, während das zugrunde liegende Netzwerkproblem weiter behoben wurde.

Am 14. Juli konnte CircleCI den Fehler mit eigenen Testtools reproduzieren. Damit bestätigte das Team, dass es sich um ein allgemeines Problem bei Git-Fetches handelte und nicht um einen Fehler, der mit einem bestimmten Build-Tool, Container-Image oder Software-Update zusammenhing. Später identifizierte der Anbieter weitere beeinträchtigte Netzwerkpfade und leitete den Traffic von ihnen weg. Anschließend markierte CircleCI den Incident als behoben.

Wie kommunizierte CircleCI?

CircleCI informierte seine Kunden während des gesamten Incidents über die öffentliche Statusseite. Die Updates zeigten, wann das Problem untersucht wurde, wann der Traffic umgeleitet worden war, wann der Incident in die Monitoring-Phase überging und wann das Problem erneut auftrat.

CircleCI veröffentlichte außerdem einen Workaround und empfahl betroffenen Kunden, no_output_timeout auf 15 bis 20 Minuten zu erhöhen. Dadurch erhielten langsame GitHub-Fetches mehr Zeit für den Abschluss, während das zugrunde liegende Netzwerkproblem weiter behoben wurde.

Nach dem Incident veröffentlichte CircleCI einen Post-Incident-Report. Darin erläuterte das Unternehmen das wiederkehrende Routing-Problem, den vorherigen Incident im Juni, die Monitoring-Lücke und die geplanten Präventionsmaßnahmen.

Wichtigste Learnings für andere Teams

• Anbieterübergreifende Netzwerkpfade überwachen: Klassisches Plattform-Monitoring kann Fehler übersehen, die zwischen externen Anbietern auftreten. Wenn ein Workflow GitHub-Fetches aus einer extern betriebenen Mac-Flotte benötigt, muss genau dieser Pfad durchgängig überwacht werden.
• Wiederholt auftretende Probleme als Warnsignal und nicht als Zufall behandeln: Ein ähnliches Routing-Problem zwischen der macOS-Infrastruktur und GitHub war bereits einige Wochen zuvor aufgetreten. Wiederkehrende Incidents sprechen dafür, dass das Fehlermuster strukturell behoben werden muss, statt jedes Ereignis nur einzeln einzudämmen.
• Incidents nicht zu früh schließen: Das Problem trat nach einer ersten Entwarnung erneut auf. Bei sporadischen Netzwerkproblemen sollte ein Incident erst nach einem ausreichend langen, unauffälligen Monitoring-Zeitraum endgültig als behoben markiert werden.
• Diagnosemöglichkeiten vor dem nächsten Incident aufbauen: CircleCI entwickelte während des Incidents Tools, um den Git-Fetch-Fehler zu reproduzieren. Werden diese dauerhaft verfügbar gemacht, lässt sich die Untersuchungszeit beim nächsten Auftreten verkürzen.
• Risiken durch die Abhängigkeit von einem einzelnen Anbieter minimieren: Der Plan von CircleCI, künftig mehrere Mac-Infrastrukturanbieter statt nur eines Providers einzusetzen, hilft, die durch diesen Incident aufgezeigten Risiken zu minimieren.

Zusammenfassung

Fast 30 Stunden lang kam es bei einigen CircleCI-Kunden mit macOS-Jobs zu erheblichen Verzögerungen und Timeouts beim Abrufen von Code und Abhängigkeiten aus GitHub. Ursache waren Kapazitäts- und Routing-Probleme auf den Netzwerkpfaden zwischen dem externen Mac-Infrastrukturanbieter und GitHub.

Ein ähnliches Routing-Problem zwischen der macOS-Infrastruktur und GitHub war bereits einige Wochen zuvor aufgetreten. Damit handelte es sich nicht um einen einmaligen Ausfall, sondern um ein wiederkehrendes Fehlermuster an der Schnittstelle zwischen mehreren Anbietern. Das automatisierte Monitoring von CircleCI erkannte diesen Fehler nicht.

CircleCI behob das Problem gemeinsam mit dem Anbieter, indem der Traffic von beeinträchtigten Netzwerkpfaden weggeleitet wurde. Zu den geplanten Präventionsmaßnahmen gehören ein End-to-End-Monitoring für GitHub-Fetches, eine schnellere Erkennung beeinträchtigter Netzwerkpfade durch den Anbieter, dauerhaft verfügbare Diagnosetools, längere Bestätigungszeiträume vor dem Schließen von Netzwerk-Incidents sowie der Wechsel zu mehreren Mac-Infrastrukturanbietern.

Grundsatz für mehr Service-Reliability: Wenn ein Kunden-Workflow davon abhängt, dass der Traffic über mehrere Anbieter läuft, sollten nicht nur die einzelnen Systeme, sondern auch die Schnittstellen zwischen ihnen überwacht werden.

So kann ilert helfen

Incidents wie der bei CircleCI zeigen, wie schwierig die Koordination der Incident Response sein kann, wenn der Fehler zwischen mehreren Anbietern liegt und nicht innerhalb eines eindeutig ausgefallenen Systems. Sobald Monitoring oder Synthetic Checks eine Beeinträchtigung erkennen, hilft ilert Teams dabei, Alarmierungen gezielt weiterzuleiten, schnell zu eskalieren und auch bei einer nur vorübergehenden Stabilisierung klar zu kommunizieren.

• Weiterleitung von Alarmierungen nach der Erkennung: Fehler bei macOS-Jobs, erhöhte GitHub-Fetch-Latenzen, steigende VCS-Timeout-Raten und fehlgeschlagene synthetische Git-Fetch-Checks werden aus Monitoring-Tools direkt an ilert übermittelt. So werden die richtigen Bereitschaftsteams benachrichtigt, sobald sich CI-Workflows verschlechtern.
• Eskalation an die richtigen Teams: Dank Dienstplänen und Eskalationsrichtlinien werden Plattform-, Infrastruktur- und Netzwerkteams sowie Ansprechpartner für externe Anbieter benachrichtigt, wenn Fetch-Verzögerungen oder Job-Timeouts kritische Schwellenwerte überschreiten.
• Information über beeinträchtigte CI-Performance: Über Statusseiten werden Kunden über verzögerte Builds, verfügbare Workarounds wie zum Beispiel höhere Timeout-Werte und über laufendes Monitoring informiert.