Störungsverlauf von Circle Ci

1. 21. Oktober 2026 um 19:31 UTCidentified

   Einige Benutzer sehen möglicherweise erhöhte Wartezeiten für Gen2 Docker-Jobs aufgrund von Kapazitätsproblemen.

2. 21. Oktober 2026 um 20:03 UTCidentified

   Wir fügen zusätzliche Kapazitäten hinzu, um das Problem zu mildern. Hinweis: Wir sehen immer noch Verzögerungen bis zu 20 Minuten auf 2xlarge.

3. 21. Oktober 2026 um 20:22 UTCidentified

   Die Wartezeiten für 2xlarge Docker Jobs erholen sich. Wir werden weiterhin aktualisieren, wenn die Kapazität online ist.

4. 21. Oktober 2026 um 20:35 UTCidentified

   Die Wartezeiten für 2xlarge Docker Jobs liegen jetzt unter 60 Sekunden. Wartezeiten für andere Ressourcengrößen wurden von diesem Vorfall nicht beeinflusst und bleiben unter 10 Sekunden.

5. 21. Oktober 2026 um 20:40 UTCmonitoring

   Wir haben eine vollständige Erholung der Wartezeiten für Docker Arbeitsplätze gesehen.

6. 21. Oktober 2026 um 20:54 UTCresolved

   Die Wartezeiten für gen2 Docker-Jobs haben sich erholt und die Jobs laufen innerhalb der normalen Wartezeiten.

7. 22. Oktober 2026 um 23:29 UTCpostmortem

   ## Zusammenfassung Von 15:44 bis 20:55 UTC am 21. Oktober sahen Kunden, die Gen 2 Docker-Jobs ausführen, erhöhte Wartezeiten für den Start ihrer Jobs. Verzögerungen waren am längsten in der 2xlarge-Ressourcenklasse, wo Jobs bis zu 20 Minuten warteten. Der Vorfall wurde durch die begrenzte Verfügbarkeit der Cloud-Instanzen verursacht, die wir für die Nachfrage konfiguriert hatten, insbesondere für 2xlarge-Jobs. Als Reaktion darauf konfigurierte unser Engineering-Team zusätzliche Instanztypen und konfigurierte zusätzliche Gen 2 Docker-Cluster. Bis 20:55 UTC waren die Wartezeiten wieder normal und der Vorfall wurde behoben. Nachdem der Vorfall behoben wurde, erweiterten wir unsere Gen 2 Docker-Flotte auf weitere Cloud-Regionen und wir setzen weiterhin aktiv auf weitere Cloud-Regionen, um ähnliche Vorfälle in Zukunft zu verhindern. Die ursprüngliche Statusseite finden Sie hier: [21. Oktober - Erhöhte Wartezeiten für Docker gen2](https://status.circleci.com/incidents/5jb50gh55gtj). ## Hintergrund Wenn CircleCI einen Docker-Job ausführt, planen wir ihn auf einem von mehreren Clustern von Cloud-Instanzen, und jede Instanz kann mehrere isolierte Jobs ausführen. Die Planung eines Auftrags in einer Cloud-Instanz ist ein klassisches [„bin packaging problem](https://en.wikipedia.org/wiki/Bin packing problem): Suche nach verfügbarer Kapazität, die zu CPU, Speicher und Speicher der angeforderten Ressourcenklasse passt. Größere Ressourcenklassen wie 2xlarge sind schwerer zu passen als kleinere, die enger zusammenpassen. Wir stellen Cloud-Instanzen mit einer Rangliste von Instanztypen bereit. Wenn der Cloud-Anbieter unsere erste Wahl nicht liefern kann, greifen wir auf den nächsten Typ auf der Liste zurück. Darüber hinaus behalten wir eine Mindestflottengröße bei: Eine Mindestanzahl von Instanzen bleibt in Betrieb, so dass wir bei geringer Nachfrage nicht auf Kapazitäten verzichten. Über dieser Mindestflottengröße fügen wir Instanzen hinzu, wenn die Nachfrage steigt. Wenn es nicht genügend Kapazität gibt, um eine Workload auszuführen, stehen wir an, bis die Kapazität verfügbar ist. ## Was geschah \(Alle Zeiten UTC\) Ab 15:44 Uhr am 21. Oktober stieg die Nachfrage nach der Gen 2 2xlarge-Ressourcenklasse stark an, und wir haben nicht schnell genug zusätzliche Kapazitäten bereitgestellt, um mitzuhalten. Unser Ingenieurteam begann zu untersuchen. Um 19:25 Uhr hatten die Wartezeiten für die Gen 2 2xlarge-Ressourcenklasse 20 Minuten erreicht, und die Wartezeiten für andere Ressourcenklassen waren ebenfalls gestiegen. Bis 19:56 Uhr hatte unser Engineering-Team zusätzliche Instanztypen für die Gen 2-Flotte konfiguriert, um mehr Kapazität online zu erhalten, und bis 19:59 Uhr haben wir diese Instanztypen bereitgestellt. Um 20:11 Uhr haben wir mehrere zusätzliche Gen 2-Cluster hinzugefügt und die Mindestflottengröße für diese Cluster erhöht. Um 20:35 Uhr kehrte die Anzahl der in die Warteschlange gestellten Jobs auf ein normales Niveau zurück, und um 20:41 Uhr begannen 95% der 2xgroßen Jobs innerhalb von 4 Sekunden. Wir haben den Vorfall um 20:55 Uhr gelöst. Nachdem wir diesen Vorfall behoben hatten, haben wir zusätzliche Cloud-Regionen für Docker-Jobs hinzugefügt, um mehr Kapazität zur Verfügung zu stellen. ## Zukünftige Prävention und Prozessverbesserung Wir haben bereits die folgenden Schritte unternommen, um die Startzeiten zu verbessern, einschließlich der Beschaffung von Kapazitäten von mehr Orten aus, der Reservierung von mehr Kapazitäten für große Ressourcenklassen und der Umsetzung einer schnelleren Bereitstellung. **Wir haben zusätzliche Regionen für Docker-Jobs hinzugefügt.** Wir haben kürzlich zusätzliche Cloud-Regionen für Machine-Jobs hinzugefügt, und wir haben jetzt dasselbe für Docker-Jobs getan. **Wir werden weiterhin aktiv zusätzliche Cloud-Regionen für Docker- und Machine-Jobs hinzufügen**. **Wir haben zusätzliche Gen 2-Cluster hinzugefügt**. Wir haben mehrere zusätzliche Gen 2-Cluster konfiguriert, um Aufträge schneller zu planen und mehr Gesamtkapazität zur Verfügung zu stellen. **Wir haben den Satz der von uns verwendeten Cloud-Instanztypen erweitert und unsere Mindestflottengröße erhöht. ** Wir haben zusätzliche Instanztypen konfiguriert. Wir haben auch die Mindestflottengröße für Gen 2 erhöht, um die aktuelle Basisnachfrage zu decken. **Wir haben unseren Jobplaner geändert, um die Planung größerer Ressourcenklassen zu priorisieren. ** Wir haben geändert, wie wir Jobs planen, um die Wartezeiten in den Ressourcenklassen gerechter auszugleichen und Jobs effizienter auf verfügbare Instanzen zu verteilen. ## Schlussfolgerung Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Wir danken unseren Kunden für ihre Geduld, während unser Team daran arbeitete, diesen Vorfall zu lösen. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 15:58 UTCinvestigating

   Wir sehen erhöhte Wartezeiten für einige macOS-Jobs mit der Ressourcenklasse m4pro.large. Wir untersuchen und werden bald ein weiteres Update bereitstellen. Vielen Dank für Ihre Geduld.

2. 20. Oktober 2026 um 16:32 UTCmonitoring

   Kunden, die macOS-Jobs in der Ressourcenklasse m4pro.large ausführen, sehen immer noch erhöhte Wartezeiten, wobei einige Jobs bis zu 30 Minuten auf den Start warten. Wir überwachen dies weiterhin und werden in Kürze ein weiteres Update veröffentlichen.

3. 20. Oktober 2026 um 17:02 UTCmonitoring

   Die Wartezeiten für m4pro.large sind aufgrund der hohen Nachfrage immer noch erhöht. Alle m4pro.medium sind normal. Wir beobachten aktiv, wir schätzen Geduld.

4. 20. Oktober 2026 um 17:31 UTCmonitoring

   Die Wartezeiten für macOS-Jobs in der Ressourcenklasse m4pro.large erholen sich. Jobs mit Xcode 27.0 warten jetzt durchschnittlich etwa 3,5 Minuten, gegenüber etwa 40 Minuten auf dem Höhepunkt. Jobs mit Xcode 26.6 und 26.4.1 arbeiten immer noch durch einen Backlog, der gelöscht wird. Wartezeiten auf m4pro.medium sind normal. Wir werden bald ein weiteres Update teilen, wenn wir die Überwachung fortsetzen.

5. 20. Oktober 2026 um 18:14 UTCresolved

   Die Wartezeiten für macOS-Jobs in der Ressourcenklasse m4pro.large sind wieder normal. Wir danken Ihnen für Ihre Geduld, während der Rückstand beseitigt wurde.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. Oktober 2026 um 14:47 UTCinvestigating

   Seit ca. 14:00 UTC haben Kunden, die macOS-Jobs ausführen, die Xcode 26.6.0 in der großen Ressourcenklasse M4 Pro verwenden, Verzögerungen beim Starten von Jobs. Die Wartezeiten haben 30 Minuten oder mehr erreicht. Vielen Dank für Ihre Geduld, während unsere Ingenieure untersuchen. Wir werden ein weiteres Update bis 15:30 UTC zur Verfügung stellen.

2. 14. Oktober 2026 um 15:17 UTCidentified

   Verzögerungen beim Starten von macOS-Jobs, die Xcode 26.6.0 verwenden, wurden wiederhergestellt. Seit etwa 15:11 UTC haben macOS-Jobs, die Xcode 26.4 verwenden, Verzögerungen mit Wartezeiten von etwa 30 Minuten. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, dies zu lösen. Wir werden ein weiteres Update von 15:45 UTC zur Verfügung stellen.

3. 14. Oktober 2026 um 16:01 UTCresolved

   Zwischen ca. 14:00 UTC und 15:51 UTC am 14. Oktober erlebten Kunden, die macOS-Jobs mit Xcode 26.6.0 oder Xcode 26.4 ausführen, Verzögerungen beim Starten von Jobs. Ab ca. 14:00 Uhr UTC warteten Jobs, die Xcode 26.6.0 auf der M4 Pro Large-Ressourcenklasse verwendeten, 30 Minuten oder mehr, um zu starten, und diese Verzögerungen erholten sich um ca. 15:12 Uhr UTC. Ab ca. 15:11 UTC warteten Jobs, die Xcode 26.4 verwenden, etwa 30 Minuten, um zu starten. Das Problem wurde behoben und alle betroffenen Funktionen haben sich wieder normalisiert. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 9. Oktober 2026 um 11:33 UTCidentified

   Es gibt eine Verzögerung in unserer Dateninfrastruktur, die Verzögerungen verursacht, bevor Daten erstellt werden und einige Benachrichtigungen sichtbar werden. Wir arbeiten an einer Minderung.

2. 9. Oktober 2026 um 13:00 UTCidentified

   Was ist betroffen: Kunden, die Pipelines auslösen, und Kunden, die auf ausgehende Webhooks und E-Mail- und Slack-Benachrichtigungen angewiesen sind. Was können Sie erwarten Seit 11:15 UTC: - Pipelines werden noch erstellt, während dies noch läuft, aber noch nicht verarbeitet wird, so dass das Retriggern zu doppelten Pipelines führen kann. Outbound Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) werden nicht gesendet. Pipeline-Status sind möglicherweise nicht sichtbar. - Nutzungsgebührendaten auf der Projektnutzungsseite sind veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, dies zu lösen. Nächste Aktualisierung: Wir werden ein weiteres Update bis 13:30 UTC zur Verfügung stellen.

3. 9. Oktober 2026 um 13:30 UTCidentified

   Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Was ist betroffen: Kunden, die Pipelines auslösen, und Kunden, die auf ausgehende Webhooks und E-Mail- und Slack-Benachrichtigungen angewiesen sind. Was können Sie erwarten: - Seit ca. 13:00 UTC werden Pipelines wieder bearbeitet und die Jobs beginnen. - Die meisten Jobs beginnen derzeit innerhalb von etwa 4 Minuten, und einige warten bis zu etwa 10 Minuten. Pipelines, die während des Vorfalls ausgelöst werden, werden noch verarbeitet und können länger dauern. Outbound Webhooks und Benachrichtigungen wurden wieder aufgenommen. Pipelines werden immer noch aus dem Backlog verarbeitet, so dass Retriggering zu doppelten Pipelines führen kann. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, dies zu lösen. Nächste Aktualisierung: Wir werden ein weiteres Update bis 14:00 UTC zur Verfügung stellen.

4. 9. Oktober 2026 um 14:00 UTCidentified

   Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Was ist betroffen Kunden, die Workflows und Aufträge ausführen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten - Pipelines werden erneut bearbeitet, einschließlich derjenigen, die während des Vorfalls ausgelöst wurden. - Seit etwa 13:25 UTC beginnen Workflows und Jobs mit zunehmenden Verzögerungen, während wir den Backlog durcharbeiten. Die meisten Jobs beginnen derzeit innerhalb von etwa 10 Minuten, und einige warten bis zu etwa 25 Minuten. - Wir erwarten, dass durch diesen Rückstand von etwa 14:35 UTC arbeiten. - Workflows aus Pipelines, die während des Vorfalls ausgelöst werden, warten immer noch auf den Start, so dass das Retriggern zu doppelten Workflows führen kann. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, dies zu lösen. Nächstes Update Wir werden ein weiteres Update bis 14:30 UTC zur Verfügung stellen.

5. 9. Oktober 2026 um 14:29 UTCidentified

   Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Was ist betroffen Kunden, die Workflows und Aufträge ausführen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten Verzögerungen beim Starten von Workflows und Jobs verbessern sich. Die meisten Jobs beginnen jetzt innerhalb von etwa 3 Minuten, von etwa 10 Minuten um 13:50 UTC. Einige Workflows aus Pipelines, die während des Vorfalls ausgelöst wurden, warten immer noch bis zu 40 Minuten, um zu starten. Die Bearbeitung des Backlogs dauert etwas länger als erwartet. Wir erwarten jetzt, es um etwa 14:45 UTC zu löschen. - Workflows aus Pipelines, die während des Vorfalls ausgelöst werden, warten immer noch auf den Start, so dass das Retriggern zu doppelten Workflows führen kann. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, dies zu lösen. Nächstes Update Wir werden ein weiteres Update bis 15:00 UTC zur Verfügung stellen.

6. 9. Oktober 2026 um 14:43 UTCidentified

   Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Was ist betroffen Kunden, die Workflows und Aufträge ausführen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten - Der Rückstand von Workflows aus Pipelines, der während des Vorfalls ausgelöst wurde, wurde um etwa 14:40 UTC gelöscht. Die meisten Jobs beginnen jetzt innerhalb von etwa 30 Sekunden und einige warten bis zu etwa 3 Minuten. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure weiter an dem zugrunde liegenden Problem arbeiten. Nächstes Update Wir werden ein weiteres Update bis 15:10 UTC zur Verfügung stellen.

7. 9. Oktober 2026 um 14:54 UTCmonitoring

   Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Was ist betroffen Kunden, die Workflows und Aufträge ausführen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten - Der Rückstand an Pipelines und Workflows aus dem Vorfall ist behoben. - Seit etwa 14:45 UTC beginnen die meisten Workflows und Jobs innerhalb von etwa 15 Sekunden, und die Startzeiten kehren weiter zum Normalzustand zurück. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure die Wiederherstellung überwachen. Nächstes Update Wir werden ein weiteres Update von 15:20 UTC zur Verfügung stellen.

8. 9. Oktober 2026 um 15:32 UTCmonitoring

   Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Was ist betroffen Kunden, die Pipelines, Workflows und Jobs in der CircleCI-Benutzeroberfläche anzeigen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten Workflows und Jobs laufen pünktlich. - Die CircleCI UI liegt etwa 30 Minuten zurück. Neue Workflows und Statusänderungen können so lange dauern. - Unsere Ingenieure arbeiten aktiv daran, die Verarbeitung zu beschleunigen, damit die Benutzeroberfläche aufholen kann. - Bitte vermeiden Sie es, Workflows neu auszulösen, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, diese Verzögerung zu reduzieren. Nächstes Update Wir werden ein weiteres Update bis 16:00 UTC zur Verfügung stellen.

9. 9. Oktober 2026 um 16:02 UTCmonitoring

   Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Was ist betroffen Kunden, die Workflows und Jobs ausführen, Kunden, die Pipelines, Workflows und Jobs in der CircleCI-Benutzeroberfläche anzeigen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten - Seit etwa 15:15 UTC beginnen Workflows und Jobs mit zunehmenden Verzögerungen. Die meisten Jobs beginnen derzeit innerhalb von etwa 4 Minuten, und einige warten bis zu etwa 20 Minuten. - Die CircleCI-Benutzeroberfläche bleibt im Durchschnitt etwa 30 Minuten zurück und einige Updates dauern länger. Neue Workflows und Statusänderungen können so lange dauern. - Bitte vermeiden Sie es, Workflows neu auszulösen, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, diese Verzögerungen zu reduzieren. Nächstes Update Wir werden ein weiteres Update bis 16:30 UTC zur Verfügung stellen.

10. 9. Oktober 2026 um 16:32 UTCmonitoring

    Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Seit ca. 15:15 UTC beginnen Workflows und Jobs wieder mit Verzögerungen. Was ist betroffen Kunden, die Workflows und Jobs ausführen, Kunden, die Pipelines, Workflows und Jobs in der CircleCI-Benutzeroberfläche anzeigen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten Verzögerungen beim Starten von Workflows und Jobs haben aufgehört zu steigen und beginnen sich zu entspannen. Die meisten Jobs beginnen innerhalb von etwa 4 Minuten und einige warten bis zu etwa 25 Minuten. - Die CircleCI UI ist jetzt etwa 20 Minuten zurück, nach etwa 30 Minuten. Neue Workflows und Statusänderungen können so lange dauern. - Bitte vermeiden Sie es, Workflows neu auszulösen, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, diese Verzögerungen zu reduzieren. Nächstes Update Wir werden ein weiteres Update bis 17:00 UTC zur Verfügung stellen.

11. 9. Oktober 2026 um 17:06 UTCmonitoring

    Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Seit ca. 15:15 UTC beginnen Workflows und Jobs wieder mit Verzögerungen. Was ist betroffen Kunden, die Workflows und Jobs ausführen, Kunden, die Pipelines, Workflows und Jobs in der CircleCI-Benutzeroberfläche anzeigen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten Verzögerungen beim Starten von Workflows und Jobs halten sich stabil. Die meisten Jobs beginnen innerhalb von etwa 4 Minuten, und einige warten bis zu etwa 8 Minuten, von etwa 25 Minuten. - Die CircleCI-Benutzeroberfläche bleibt im Durchschnitt etwa 20 Minuten zurück und einige Updates dauern länger. Neue Workflows und Statusänderungen können so lange dauern. - Bitte vermeiden Sie es, Workflows neu auszulösen, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, diese Verzögerungen zu reduzieren. Nächstes Update Wir werden ein weiteres Update bis 17:30 UTC zur Verfügung stellen.

12. 9. Oktober 2026 um 17:34 UTCidentified

    Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Seit ca. 15:15 UTC beginnen Workflows und Jobs wieder mit Verzögerungen. Was ist betroffen Kunden, die Pipelines auslösen und Workflows und Jobs ausführen, Kunden, die Pipelines, Workflows und Jobs in der CircleCI-Benutzeroberfläche anzeigen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was können Sie erwarten - Seit etwa 17:00 UTC haben die Verzögerungen deutlich zugenommen. Die meisten Jobs brauchen jetzt etwa 12 Minuten, um zu beginnen, und einige warten bis zu etwa 30 Minuten. - Seit etwa 17:15 UTC, einige Jobs sind nicht zu starten. Pipelines werden langsamer verarbeitet, so dass einige länger dauern können, um zu starten. - Die CircleCI UI ist mehr als eine Stunde zurück. Neue Workflows und Statusänderungen können so lange dauern. - Bitte vermeiden Sie es, Workflows neu auszulösen, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Vielen Dank für Ihre Geduld, während unsere Ingenieure daran arbeiten, dies zu lösen. Nächstes Update Wir werden ein weiteres Update bis 18:00 UTC zur Verfügung stellen.

13. 9. Oktober 2026 um 18:08 UTCidentified

    Seit 11:15 UTC haben Kunden Störungen bei Pipelines und Benachrichtigungen erlebt. Zwischen 11:15 UTC und ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Transaktionsbenachrichtigungen (Slack und E-Mail) wurden nicht gesendet. Zwischen ca. 13:00 UTC und 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Seit ca. 15:15 UTC beginnen Workflows und Jobs wieder mit Verzögerungen. Was ist betroffen Kunden, die Pipelines auslösen und Workflows und Jobs ausführen, Kunden, die Pipelines, Workflows und Jobs in der CircleCI-Benutzeroberfläche anzeigen, und Kunden, die Nutzungsdaten auf der Projektnutzungsseite anzeigen. Was zu erwarten ist - Seit etwa 17:00 UTC sehen wir einen Anstieg der Verzögerungen. Die meisten Jobs brauchen jetzt etwa 25 Minuten, um zu beginnen, und einige warten bis zu etwa einer Stunde. - Seit etwa 17:15 UTC sind einige laufende Workflows fehlgeschlagen und eine kleine Anzahl von Jobs kann nicht starten. - Neue Pipelines werden Schlange gestellt und brauchen länger, um zu starten. - Die CircleCI UI ist mehr als eine Stunde zurück. Neue Workflows und Statusänderungen können so lange dauern. - Bitte vermeiden Sie es, Workflows neu auszulösen, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. - Nutzungsgebührendaten auf der Projektnutzungsseite sind derzeit veraltet. Unsere Ingenieure arbeiten weiter daran, das Problem zu lösen. Nächstes Update Wir werden ein weiteres Update bis 18:30 UTC zur Verfügung stellen.

14. 9. Oktober 2026 um 18:32 UTCidentified

    Was sich seit unserem letzten Update geändert hat * Die CircleCI-Benutzeroberfläche liegt etwa eine Stunde zurück und für einige Updates bis zu 90 Minuten. Workflows und Jobs sind möglicherweise bereits ausgeführt oder laufen bereits, auch wenn die Benutzeroberfläche sie als nicht gestartet anzeigt oder überhaupt nicht anzeigt. * Jobs, die laufen, beginnen schneller. Die meisten beginnen jetzt innerhalb von etwa 15 Minuten, von etwa 28 Minuten, obwohl einige immer noch über eine Stunde warten. * Neue Pipelines werden zunehmend verzögert. * Einige Workflows scheitern immer noch. Workflows, die nicht rechtzeitig bearbeitet werden konnten, werden als fehlgeschlagen markiert. * Bitte vermeiden Sie das erneute Auslösen von Workflows, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. Noch nicht abgeschlossen: Nutzungsgebührendaten auf der Projektnutzungsseite sind veraltet. Nächstes Update Wir werden ein weiteres Update bis 19:00 UTC zur Verfügung stellen.

15. 9. Oktober 2026 um 18:57 UTCidentified

    Was sich seit unserem letzten Update geändert hat * Jobs beginnen schneller. Die meisten beginnen jetzt innerhalb von etwa 8 Minuten, von etwa 15 Minuten, und die längsten Wartezeiten sind von über einer Stunde auf etwa 45 Minuten gesunken. * Die CircleCI-Benutzeroberfläche fängt an aufzuholen, liegt aber immer noch zurück. Workflows und Jobs sind möglicherweise bereits ausgeführt oder laufen bereits, auch wenn die Benutzeroberfläche sie als nicht gestartet anzeigt oder überhaupt nicht anzeigt. * Pipelines werden schneller verarbeitet, aber neue Pipelines sind immer noch verzögert. Noch nicht abgeschlossen * Einige Workflows und Jobs scheitern immer noch. * Bitte vermeiden Sie das erneute Auslösen von Workflows, die noch nicht in der Benutzeroberfläche erscheinen, da dadurch Duplikate erstellt werden können. * Nutzungsgebührendaten auf der Projektnutzungsseite sind veraltet. Nächstes Update Wir werden ein weiteres Update bis 19:30 UTC zur Verfügung stellen.

16. 9. Oktober 2026 um 19:29 UTCidentified

    Seit unserem letzten Update beginnen die Jobs schneller: Die meisten beginnen jetzt innerhalb von etwa 6 Minuten, gegenüber etwa 8 Minuten. Die CircleCI-Benutzeroberfläche holt auf, liegt aber immer noch etwa eine Stunde zurück. Neue Pipelines werden bearbeitet, sobald sie ankommen. Jobs sind möglicherweise bereits ausgeführt, auch wenn die Benutzeroberfläche sie noch nicht anzeigt, also vermeiden Sie bitte das erneute Auslösen von Workflows, die nicht in der Benutzeroberfläche angezeigt werden. Wir werden ein weiteres Update bis 20:00 UTC zur Verfügung stellen.

17. 9. Oktober 2026 um 20:06 UTCidentified

    Jobs beginnen schneller und weniger scheitern: Die meisten Jobs beginnen jetzt innerhalb von etwa 4 Minuten, von etwa 6 Minuten, und die längsten Wartezeiten sind von etwa 30 Minuten auf etwa 20 Minuten gesunken. Pipelines von früher in dem Vorfall werden jetzt durchgearbeitet. Die CircleCI-Benutzeroberfläche liegt immer noch zurück, und einige ältere Updates können länger dauern. Jobs sind möglicherweise bereits ausgeführt, auch wenn die Benutzeroberfläche sie noch nicht anzeigt, also vermeiden Sie bitte das erneute Auslösen von Workflows, die nicht in der Benutzeroberfläche angezeigt werden. Wir werden ein weiteres Update bis 20:30 UTC zur Verfügung stellen.

18. 9. Oktober 2026 um 21:22 UTCidentified

    Seit ca. 20:48 UTC starten neue Workflows und Jobs nicht mehr. Wir haben den Beginn neuer Arbeiten vorübergehend unterbrochen, damit unsere Systeme bereits laufende Arbeiten einholen können, einschließlich verzögerter Updates für die CircleCI-Benutzeroberfläche und -API. Ältere Updates erscheinen jetzt in der Benutzeroberfläche und API, wenn dieser Backlog gelöscht wird. Neue Pipelines werden immer noch akzeptiert und in die Warteschlange gestellt Bitte vermeiden Sie während dieser Zeit das erneute Auslösen von Pipelines oder Workflows, da dadurch Duplikate erstellt werden können, sobald die Arbeit wieder aufgenommen wird. Wir werden ein weiteres Update bis 22:00 UTC zur Verfügung stellen.

19. 9. Oktober 2026 um 22:09 UTCidentified

    Seit unserem letzten Update wurden die meisten Pipelines, die früher im Vorfall verzögert wurden, jetzt verarbeitet und ihre Workflows stehen in der Warteschlange, um zu starten. Neue Workflows und Jobs bleiben pausiert, während wir uns darauf vorbereiten, die Arbeit sicher fortzusetzen. Verzögerte Updates erscheinen weiterhin in der CircleCI UI und API. Bitte vermeiden Sie weiterhin das erneute Auslösen von Pipelines oder Workflows, da dadurch Duplikate erstellt werden können, sobald die Arbeit wieder aufgenommen wird. Wir werden ein weiteres Update bis 22:30 UTC zur Verfügung stellen.

20. 9. Oktober 2026 um 22:28 UTCidentified

    Seit unserem letzten Update haben wir begonnen, die Arbeit schrittweise wieder aufzunehmen, und einige in die Warteschlange gestellte Workflows und Jobs beginnen wieder. Die meisten Schlangenarbeiten warten immer noch, und Jobs, die beginnen, haben möglicherweise über eine Stunde gewartet. Wir erhöhen die Rate vorsichtig, um eine Überlastung unserer Systeme zu vermeiden. Verzögerte Updates erscheinen weiterhin in der CircleCI UI und API. Bitte vermeiden Sie weiterhin das erneute Auslösen von Pipelines oder Workflows, da dies zu Duplikaten führen kann, wenn die Arbeit in der Warteschlange fortgesetzt wird. Wir werden ein weiteres Update bis 23:00 UTC zur Verfügung stellen.

21. 9. Oktober 2026 um 23:00 UTCidentified

    Eine große Anzahl von Workflows und Jobs in der Warteschlange hat begonnen, und die CircleCI-Benutzeroberfläche und -API haben aufgeholt und zeigen normalerweise mit wenigen Verzögerungen Updates an. Wir arbeiten weiter an der verbleibenden Arbeit in der Warteschlange. Jobs aus der Warteschlange haben möglicherweise etwa eine Stunde oder länger auf den Start gewartet, und einige Linux-Jobs warten bis zu etwa 10 Minuten auf die Kapazität. Bitte vermeiden Sie weiterhin Retriggering, während die Arbeit in der Warteschlange weiterverarbeitet wird. Wir werden ein weiteres Update bis 23:30 UTC zur Verfügung stellen.

22. 9. Oktober 2026 um 23:38 UTCidentified

    Wir arbeiten immer noch durch einen erheblichen Rückstand an in die Warteschlange gestellten Workflows und Jobs. Die Wartezeiten verbessern sich, aber sie bleiben länger als normal und einige Jobs haben über eine Stunde gewartet. Die CircleCI UI und API bleiben auf dem neuesten Stand. Bitte vermeiden Sie das erneute Auslösen von Pipelines oder Workflows, während der Backlog gelöscht wird, da dadurch Duplikate erstellt werden können. Wir werden ein weiteres Update bis 00:00 UTC zur Verfügung stellen.

23. 9. Oktober 2026 um 23:59 UTCidentified

    Seit unserem letzten Update hat sich der Rückstand der in der Warteschlange stehenden Workflows und Jobs verringert, ab ca. 23:47 UTC. Workflows und Jobs starten nun innerhalb von Sekunden und die CircleCI UI und API sind auf dem neuesten Stand. Wir überwachen unsere Systeme genau, um sicherzustellen, dass sie stabil bleiben. Wir werden ein weiteres Update bis 00:30 UTC zur Verfügung stellen.

24. 10. Oktober 2026 um 00:45 UTCidentified

    Workflows und Jobs haben innerhalb von Sekunden normal begonnen und die CircleCI-Benutzeroberfläche und -API bleiben auf dem neuesten Stand. Slack- und e-mail-benachrichtigungen, die sich früher im vorfall verzögert haben, werden immer noch zugestellt. Nutzungsgebührendaten auf der Projektnutzungsseite sind veraltet. Wir überwachen unsere Systeme weiterhin genau und werden bis 01:15 UTC ein weiteres Update bereitstellen.

25. 10. Oktober 2026 um 01:23 UTCmonitoring

    Workflows und Jobs starten und laufen normal, und die CircleCI UI und API sind auf dem neuesten Stand. Wir überwachen unsere Systeme weiterhin genau, um sicherzustellen, dass sie stabil bleiben. Wir werden ein weiteres Update von 02:00 UTC zur Verfügung stellen.

26. 10. Oktober 2026 um 02:08 UTCresolved

    Zwischen 11:15 UTC und 23:47 UTC am 9. Oktober erlebten Kunden Verzögerungen und Ausfälle in Pipelines, Workflows und Jobs sowie Verzögerungen in der CircleCI-Benutzeroberfläche, API und Benachrichtigungen. Von 11:15 bis ca. 13:00 UTC wurden Pipelines erstellt, aber nicht verarbeitet, und ausgehende Webhooks und Slack- und E-Mail-Benachrichtigungen wurden nicht gesendet. Von ca. 13:00 bis 14:40 UTC begannen Workflows und Jobs mit Verzögerungen, während wir den Backlog durcharbeiteten. Von etwa 15:15 bis 20:48 UTC begannen Workflows und Jobs mit zunehmenden Verzögerungen von bis zu etwa einer Stunde, und die CircleCI-Benutzeroberfläche und -API fielen um bis zu etwa 2 Stunden zurück. Während dieser Zeit konnten einige Jobs nicht starten und einige laufende Workflows scheiterten. Von 20:48 bis ca. 22:10 UTC haben wir vorübergehend angehalten, neue Workflows und Jobs zu starten, damit sich unsere Systeme erholen konnten. Neue Pipelines wurden in dieser Zeit akzeptiert und angestellt. Von etwa 22:10 bis 23:47 UTC wurden Workflows und Jobs in die Warteschlange gestellt und verarbeitet. Einige von ihnen hatten bis zu 2 Stunden gewartet. Das Problem wurde behoben und alle betroffenen Funktionen haben sich wieder normalisiert. Nutzungsgebührendaten auf der Projektnutzungsseite sind noch nicht auf dem neuesten Stand und werden aktualisiert, sobald unsere Daten-Backfills abgeschlossen sind. Kunden, deren Jobs in diesem Fenster fehlgeschlagen sind, können betroffene Jobs erneut ausführen. Wir danken Ihnen für Ihre Geduld, während unsere Ingenieure an der Implementierung eines Fixes gearbeitet haben.

27. 12. Oktober 2026 um 22:32 UTCpostmortem

    ## Summary Between 11:15 UTC and 23:47 UTC on October 9, CircleCI customers experienced hours-long delays and failures across pipelines, workflows and jobs, along with delays in the CircleCI UI, API and notifications. * From 11:15 to 13:00 UTC, pipelines were created but not processed, and outbound webhooks and Slack and email notifications were not sent. * From 13:00 to 14:40 UTC, workflows and jobs started with delays while we worked through the backlog. * From 15:15 to 20:48 UTC, workflows and jobs started with increasing delays, of up to about an hour, and the CircleCI UI and API fell behind by up to about 2 hours. During this time, some jobs failed to start and some in-progress workflows failed. * From 20:48 to 22:10 UTC, we temporarily paused starting new workflows and jobs so our systems could recover. New pipelines were accepted and queued during this time. * From 22:10 to 23:47 UTC, queued workflows and jobs resumed and were successfully processed. Some of them had waited up to about 2 hours. * By 23:47, the incident was mitigated. The status page for this incident can be found at [October 9 - Delay in data appearing in UI and API](https://status.circleci.com/incidents/6cfhhlr4rmm0). Customers experienced a similar incident earlier in the week at [October 6 - Delays in pipelines, workflows, UI data, and notifications](https://status.circleci.com/incidents/z4hbq8h49j8c). Multiple CircleCI services use Temporal backed by Postgres as a reliable queueing mechanism, and both incidents had the same cause: the rate of writes to Temporal's Postgres instance were faster than Postgres’s transaction log could archive those writes. In both cases, this caused multi-hour delays in processing both pipelines and status notifications. We evaluated several mitigations, then paused new workflow starts so the system could recover safely, and ramped back up gradually. We then throttled work back up until our systems returned to normal. To permanently resolve the bottleneck, we have split work across multiple Temporal instances, each with its own independent database and worker clusters, and we load-balance across them. We had already scheduled infrastructure work starting the week of October 12 that would have removed this exact bottleneck and prevented these incidents. So starting 19:11 on October 9 our engineering team implemented, tested, and rolled out a simpler version of these changes within a few hours. We further added new alerting and tuned the underlying databases for better performance under high load. Customers whose jobs failed during this window may rerun them. ## Background To run customer jobs, CircleCI executes a series of steps: we accept customer pipelines; we assign jobs for those pipelines to workers; we deliver status updates for those pipelines and jobs; and we charge customers for the credits those jobs consume. Each of these steps is implemented by an independent service, with reliable queues in between. Historically we have implemented these reliable queues with RabbitMQ on top of durable storage, with exponential backoff and dead letter queues for reliability. Over the last year, we have increasingly reimplemented our reliable queues on [Temporal](https://temporal.io/), which provides far better durability and reliability guarantees over a simpler and more powerful programming model. Our build service \(which turns a pipeline config into an executable plan\), our workflow orchestrator service \(which distributes tasks onto workers\), our notification service \(which delivers status updates\), and our charging service \(which charges customers for credits\) all now use Temporal. Temporal stores the state for its workflows and activities \(called “history”\) in a database, and this is the only component in a Temporal instance that is synchronous and stateful. As a consequence, a Temporal instance’s ability to accept and execute workflows is dependent on the write rate of its backing database. We have also configured Temporal to delete completed workflows and activities from its history 3 days after they complete. At the time of this incident, we used a single clustered Temporal instance backed by a Multi-AZ Postgres RDS instance for all of these reliable queues. While a Multi-AZ RDS instance is resilient to zone failures, it maintains database consistency via a single write-ahead-log \(WAL\). At the time we had configured our Postgres instance to store its WAL on a Dedicated Log Volume \(DLV\) so log writes did not compete with data writes. The database archives the log continuously to backup storage, and it can only reuse space on the volume after the log has been archived. If the database writes logs faster than it archives, the volume fills and Postgres has no space to the write its WAL log. Then the database stops accepting incoming writes and goes entirely read-only. An RDS DLV is limited to 1TB of storage and 3000 IOPS and per AWS these limits are hardcoded and cannot be increased. ## What Happened _\(All times UTC\)_ One of the contributing factors to the October 6 incident was that we were processing a high rate of Temporal history deletions at the same time as incoming work, which in turn put pressure on the backing database. To resolve the October 6 incident, we changed cleanup settings on Temporal’s largest tables and moved the transaction log back to its dedicated volume. These changes eliminated the major source of transaction log writes, but did not consider the additional log writes from scheduled deletions. Because we have configured Temporal to delete completed workflows and activities from its history 3 days after they complete, the October 6 history was scheduled to be deleted on October 9. Starting at 08:00 on October 9, Temporal began processing those scheduled deletions, and as a consequence free space on the Postgres DLV began dropping precipitously, from 0.8TB at 08:00 to 0.1TB by 10:10. Our monitoring alerted at 10:28 and we declared an incident at 10:31. While our infrastructure team was investigating, at 11:15 the DLV ran out of space and the Postgres instance went read-only. This stopped all Temporal processing in its tracks. At 11:42, we restarted Postgres to move the WAL log from the DLV onto the data volume and use the spare disk space and IOPS there. This maneuver had mitigated the incident on October 6, and we knew it would take roughly 60 minutes. While the database was restarting, we began implementing several load-shedding techniques upstream of Temporal: * We began investigating whether we should shed incoming workloads altogether to keep the rest moving, but ultimately decided that this would provide no value. * At 12:29, we flagged off credit charging updates, which represented 12% of Temporal activities. This left the Pipeline Usage page with stale charging data, until we would backfill it, but would not lose data or prevent pipelines from running. At 12:59, the database was back up and began processing work that had queued since 11:15 and by 14:40, this backlog had cleared and jobs were starting on time. However, by 15:15, delays returned as database’s routing cleanup had fallen far behind on the tables Temporal uses to track queued and scheduled work. Those tables normally hold tens of thousands of deleted rows awaiting cleanup, but by late afternoon, they held tens of millions of rows. Every Temporal operation had to read past those rows, so the database spent much more processing time on each one and Temporal ran slower. This resulted in customers continuing to see hour-long delays in starting pipelines and in status updates. For the next several hours we attempted various mitigations, including: * Manipulating Temporal configuration values to reduce database pressure. This had minimal effect. * Running manual vacuum jobs to clean up dead rows in Postgres. This ended up competing for CPU with queries themselves, and was ultimately counterproductive. We cancelled them at 17:45 to relieve the pressure on the database load. * We began trying to move all of the notification usecases to a separate Temporal instance. This represented 18% of Temporal activities. We successfully finished moving notifications by 17:07. * At 17:16, we successfully implemented an optimization in our representation of pipeline state, which reduced it by 5%. That in turn reduced the size of database writes and therefore data pressure on the Postgres WAL log. None of these fully mitigated the issue. By 20:48, we realized that Postgres was now thrashing on database CPU and was no longer bottlenecked on log writes. We further realized that our upstream systems were both submitting new work and also retrying work that had earlier been submitted and failed. Recognizing that we were in a classic retry storm, we paused all incoming and retry work and let it queue up, in order to allow the database to fully complete in-process work. We then slowly throttled up queued work from 22:07 to keep the database at a sustainable load. This fully succeeded by 23:47 when all queued work had started, and we closed the incident at 02:08 on October 10. ## Future Prevention and Process Improvement ### Multiple Temporal Instances In parallel with incident mitigation and resolution, starting at 19:11 on October 9, we also began standing up multiple sharded Temporal instances and implementing the ability to load-balance incoming work between them. Each of the multiple Temporal instances maintains its own independent database and worker clusters, and so is isolated from the others. As a postmortem action item from the October 6 incident, we had already scheduled infrastructure work that would have removed the bottleneck of a single Temporal instance and Postgres database, starting October 12 and expecting to take 2 weeks. On October 9, we realized that this work simply could not wait, so our engineering team implemented, tested, and rolled out a simpler version of the planned changes within a few hours. These changes completed successfully at 01:45 on October 10. **In addition, we are changing how we store and monitor transaction logs.** Our Temporal database no longer uses the fixed-size log volume. We are adding alerts on how far log archiving falls behind and how fast the database writes logs, so we can act hours earlier than we did on October 9. **We are also revisiting the Temporal's deletion schedule.** Temporal deletes finished work a few days after it runs, so a busy day returns as database load later in the week. We are changing when and how quickly those deletions run. **We are changing how our systems retry when Temporal is slow.** On October 9, our systems retried failed work against Temporal and added to its load. As we committed after the October 6 incident, we are changing our systems to wait for Temporal to recover so work is not dropped. ## Conclusion Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. We thank our customers for their patience while our team worked to resolve these incidents. Please reach out to our support team with any questions or concerns.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 13:00 UTCidentified

   Kunden können erhöhte Wartezeiten für Maschinenjobs erleben. Wir arbeiten daran, dies zu lösen.

2. 8. Oktober 2026 um 13:34 UTCidentified

   Kunden, die Linux-Maschinenjobs verwenden, haben erhöhte Wartezeiten von durchschnittlich etwa 11 Minuten, wobei die längsten Wartezeiten bei den Ressourcenklassen Medium, arm.medium und arm.large 30 Minuten überschreiten. Unsere Ingenieure haben das Problem erkannt und arbeiten an einem Fix. Wir werden ein weiteres Update bis 14:00 UTC zur Verfügung stellen.

3. 8. Oktober 2026 um 14:04 UTCidentified

   Kunden, die Linux-Maschinenjobs verwenden, haben erhöhte Wartezeiten von durchschnittlich etwa 40 Minuten, wobei die längsten Wartezeiten 50 Minuten überschreiten. Die meisten Linux-Ressourcenklassen sind betroffen, einschließlich mittel, groß, xlarge, 2xlarge und deren Arm-Äquivalente. Unsere Ingenieure haben das Problem erkannt und arbeiten an einem Fix. Wir werden ein weiteres Update bis 14:30 UTC zur Verfügung stellen.

4. 8. Oktober 2026 um 14:37 UTCidentified

   Kunden, die Linux-Maschinenjobs und Remote-Docker verwenden, haben erhöhte Wartezeiten. Die Wartezeiten haben begonnen zu sinken und durchschnittlich etwa 20 Minuten, wobei die längsten Wartezeiten bei einigen Ressourcenklassen 40 Minuten überschreiten. Unsere Ingenieure haben das Problem erkannt und arbeiten an einem Fix. Wir werden ein weiteres Update bis 15:00 UTC zur Verfügung stellen.

5. 8. Oktober 2026 um 15:01 UTCidentified

   Ein Fix wurde bereitgestellt und die Wartezeiten sinken, aber Kunden, die Linux-Maschinenjobs und Remote Docker verwenden, haben immer noch Verzögerungen. Die Wartezeiten betragen derzeit durchschnittlich etwa 11 Minuten, wobei die längsten Wartezeiten bei einigen Ressourcenklassen 35 Minuten überschreiten. Wir arbeiten daran, so schnell wie möglich Kapazitäten hinzuzufügen. Wir werden ein weiteres Update bis 15:30 UTC zur Verfügung stellen.

6. 8. Oktober 2026 um 15:31 UTCidentified

   Die Wartezeiten sinken weiter, aber Kunden, die Linux-Maschinenjobs und Remote-Docker verwenden, haben immer noch Verzögerungen. Die Wartezeiten betragen derzeit durchschnittlich etwa 6 Minuten. Die längsten Wartezeiten, bis zu etwa 20 Minuten, sind auf der 2xlarge, arm.2xlarge und gpu.nvidia. kleine Ressourcenklassen. Wir arbeiten daran, so schnell wie möglich Kapazitäten hinzuzufügen. Wir werden ein weiteres Update bis 16:00 UTC zur Verfügung stellen.

7. 8. Oktober 2026 um 15:59 UTCidentified

   Die Wartezeiten sinken weiter, aber Kunden, die Linux-Maschinenjobs und Remote-Docker verwenden, haben immer noch Verzögerungen. Die Wartezeiten betragen derzeit durchschnittlich etwa 90 Sekunden, wobei die längste Wartezeit bei einigen Ressourcenklassen bis zu 6 Minuten beträgt. Wir arbeiten daran, so schnell wie möglich Kapazitäten hinzuzufügen. Wir werden ein weiteres Update bis 16:30 UTC zur Verfügung stellen.

8. 8. Oktober 2026 um 16:09 UTCmonitoring

   Die Wartezeiten für Kunden, die Linux-Maschinenjobs und Remote-Docker verwenden, sind wieder normal. Wir überwachen, um zu bestätigen, dass die Wartezeiten stabil bleiben, während wir weiterhin Kapazitäten hinzufügen. Wir werden ein weiteres Update bis 16:30 UTC zur Verfügung stellen.

9. 8. Oktober 2026 um 16:35 UTCresolved

   Zwischen 12:40 UTC und 16:00 UTC am 8. Oktober erlebten Kunden, die Linux-Maschinenjobs und Remote-Docker verwendeten, erhöhte Wartezeiten. Das Problem wurde behoben und die Wartezeiten haben sich wieder normalisiert. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat.

10. 8. Oktober 2026 um 17:54 UTCpostmortem

    ## Zusammenfassung Seit dem 1. Oktober haben CircleCI-Kunden mehrere Vorfälle erlebt, die zu Verzögerungen und Ausfällen bei der Ausführung von Kundenpipelines geführt haben. Es gibt zwei (nicht verwandte) Ursachen, die beide vom CircleCI-Engineering-Team aktiv abgeschwächt werden: * Verfügbare Cloud Computing-Kapazität * Interne Infrastruktur ## Verfügbare Cloud Computing-Kapazität * **Problem**: Die Nachfrage nach leistungsstarken Cloud-Instanzen steigt branchenweit extrem schnell, was die Cloud-Provider-Instanztypen, die wir zur Ausführung von Kundenaufträgen verwenden, unter Druck setzt. ***Vorfälle**: * [Erhöhte Wartezeiten für Maschinenaufträge](https://status.circleci.com/incidents/jn756xtsy4xg) * [Erhöhte Aufgabenwartezeiten für Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [Erhöhte Infra-Ausfälle bei Kundenjobs](https://status.circleci.com/incidents/0z31ldjd8m5v) [Verzögerung beim Starten von Machine Job Tasks](https://status.circleci.com/incidents/tj6wdnfjwr64) [Verzögert den Start von Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * **Abmilderung und Entschließungen**: * Wir erweitern unsere Cloud-Computing-Regionen um weitere Regionen mit verfügbaren Hochleistungsinstanzen. * Wir arbeiten auch daran, zusätzliche garantierte Kapazitäten von unseren Cloud-Computing-Partnern in unseren bestehenden Regionen zu sichern. * Wir erweitern die Anzahl der Instanztypen, die wir unseren Kunden anbieten können. * Wir werden einen detaillierten Vorfallsbericht über diese Vorfälle am 9. Oktober 2026 veröffentlichen. ## Interne Infrastruktur * **Problem**: Wir weisen Kundenworkflows über einen Workflow-Orchestrierungsdienst mehreren Compute-Anbietern zu. Dieser Dienst wird derzeit durch den Schreibdurchsatz einer einzigen Datenbank gesteuert. ***Vorfälle:** [Verzögerungen in Pipelines, Workflows, UI-Daten und Benachrichtigungen](https://status.circleci.com/incidents/z4hbq8h49j8c) [Notfallinstandhaltung](https://status.circleci.com/incidents/g60yc9bvvkmx) * **Abmilderung und Entschließungen**: * Bis zum 23. Oktober 2026 planen wir die Implementierung mehrerer redundanter Workflow-Orchestrierungsservice-Instanzen mit jeweils eigener Datenbank, wodurch wir die Orchestrierungslast zwischen ihnen aufteilen können. ## Unser Engagement Um Zweifel zu vermeiden, * Diese besonderen Vorfälle stehen nicht im Zusammenhang mit laufenden Ausfällen bei Github * Wir migrieren derzeit nicht unsere Infrastruktur oder Dienstleistungen * Wir sind derzeit nicht unter Cyberangriff Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Wir danken unseren Kunden für ihre Geduld, während unser Team daran gearbeitet hat, diese Vorfälle zu lösen und zukünftige Vorfälle zu verhindern. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 18:54 UTCidentified

   Es gibt eine erhöhte Wartezeit für Jobs auf Docker Gen2.

2. 7. Oktober 2026 um 19:00 UTCidentified

   Hinweis: Verzögerungen werden für Personen, die auf Docker `xlarge` und höher laufen, deutlicher.

3. 7. Oktober 2026 um 19:52 UTCmonitoring

   Wir sehen immer noch Spikes bei den Aufgabenwartezeiten, aber im Durchschnitt sehen die Wartezeiten für alle Docker Gen2 besser aus.

4. 7. Oktober 2026 um 20:05 UTCresolved

   Dieser Vorfall wurde behoben.

5. 8. Oktober 2026 um 17:54 UTCpostmortem

   ## **Zusammenfassung** Zwischen dem 1. Oktober und dem 8. Oktober 2026 erlebten CircleCI-Kunden fünf separate Vorfälle, bei denen Jobs länger als normal auf den Start warteten oder nicht starteten. Drei der Vorfälle wurden durch die begrenzte Instanzverfügbarkeit von unserem Cloud-Anbieter verursacht. Eines wurde durch ein Konfigurationsproblem in unserer Planungsinfrastruktur und eines durch Speichergrenzen eines internen Dienstes verursacht, die wir während des Vorfalls angesprochen haben. * **Oktober 1, 07:57 bis 10:24 UTC:** Docker Gen 2 Jobs warteten bis zu 30 Minuten, um zu beginnen. Ein Konfigurationsproblem verhinderte, dass die Gen 2-Planungsserver ihre leistungsstarken lokalen Festplatten verwenden konnten. Während eines Verkehrsstoßes sättigten sich die Fallback-Disks und die Jobplatzierung verlangsamte sich. * **Oktober 7, 13:27 bis 14:06 UTC:** Maschinenjobs warteten länger als normal, weil wir nicht genügend virtuelle Maschinen von unserem Cloud-Anbieter erwerben konnten. * **Oktober 7, 14:24 bis 15:21 UTC:** Einige Jobs scheiterten mit einem Infrastrukturfehler, und Workflows verzögerten sich. Der Dienst, der jedem Auftrag seine Konfiguration beim Start gibt, ist aus dem Speicher und wurde neu gestartet. * **Oktober 7, 18:49 bis 20:05 UTC:** Docker Gen 2-Jobs haben länger als normal gewartet, weil wir nicht genügend Instanzen von unserem Cloud-Anbieter erhalten konnten. * **Oktober 8, 12:48 bis 16:00 UTC:** Linux-Maschinenjobs und Remote-Docker-Jobs warteten bis zu 50 Minuten, um zu starten. Unser Cloud-Anbieter hatte nicht genug von dem von uns angeforderten Instanztyp, und ein Fehler in der Logik, die einen anderen Instanztyp auswählt, hinderte uns daran, Alternativen zu verwenden. Jobs, die während dieser Vorfälle warteten, wurden verzögert, nicht verloren. Kunden, deren Jobs mit einem Infrastrukturfehler während des Vorfalls vom 7. Oktober von 14:24 bis 15:21 UTC gescheitert sind, können sie erneut ausführen. Die ursprünglichen Statusseiten finden Sie unten: * [Oktober 1 - Verzögert den Start von Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [Oktober 7 - Verzögerung beim Starten von Machine Job Tasks](https://status.circleci.com/incidents/tj6wdnfjwr64) * [7. Oktober - Erhöhte Infra-Ausfälle bei Kundenjobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [7. Oktober - Erhöhte Aufgabenwartezeiten für Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [Oktober 8 - Erhöhte Wartezeiten für Maschinenaufträge](https://status.circleci.com/incidents/jn756xtsy4xg) ## **Hintergrund ** Jeder Job, der auf CircleCI läuft, muss berechnet werden. Woher dieser Compute kommt, hängt vom Executor ab. Docker-Jobs laufen auf Clustern von Servern, die die Arbeit für eine Flotte von Instanzen planen. Der Scheduler ist die Software auf diesen Servern, die entscheidet, welche Instanz jeden Job ausführt. Gen 2 Docker Jobs liefen auf einem solchen Cluster zum Zeitpunkt des Vorfalls vom 1. Oktober. Gen 1 Docker Jobs sind auf mehrere Cluster verteilt. Maschinenjobs, einschließlich Remote-Docker-Jobs, erhalten eine dedizierte virtuelle Maschine. Ein Remote-Docker-Job wird als Linux-Maschinenjob von der Einreichung bis zur Bereitstellung bearbeitet. Unser Maschinenbereitstellungsservice fordert jede Maschine von unserem Cloud-Anbieter in einer der beiden Regionen an, die wir normalerweise für Maschinenaufträge verwenden. Wenn der Anbieter den von uns angeforderten Instanztyp nicht bereitstellen kann, greift der Dienst zurück: Er fordert einen anderen Instanztyp oder eine andere Region aus einer von uns verwalteten Liste an. Ein Job wartet, bis eine Maschine verfügbar ist. Wenn ein Job beginnt, fragt er einen Jobkonfigurationsdienst nach seiner Konfiguration. Dieser Dienst läuft als eine Reihe von Pods, die kleine Kopien des gleichen Programms sind. Wenn zu viele Pods aufhören, tragen die verbleibenden Pods mehr Last und Jobs können nicht beginnen, bis sich der Dienst erholt hat. Diese Pfade hängen von drei Arten von Kapazitäten ab: dem Durchsatz unserer Scheduling-Systeme, der Bereitstellung von Instanzen von unserem Cloud-Anbieter und dem Speicher und der Anzahl der Kopien der Dienste, die Jobs starten. Ein Defizit in einem von ihnen lässt Jobs warten oder scheitern. ## **Was geschah ** \(Alle Zeiten UTC\) ### **Oktober 1: Docker Gen 2 Jobs verspätet sich bis zu 30 Minuten ** Um 07:44 Uhr stieg die Festplattenaktivität auf den Servern, die Gen 2 Docker-Jobs planen, auf 90% der Kapazität und blieb dort. Um 07:57 Uhr begann die Zahl der Docker-Jobs, die auf den Start warteten, zu wachsen, und die Wartezeiten stiegen damit. Eine automatisierte Benachrichtigung hat den Bereitschaftstechniker um 08:08 Uhr auf die Seite gebracht. Wir erklärten einen Vorfall um 08:42. Um 08:43 Uhr identifizierten die Ingenieure eine hohe Latenz auf den Planungsservern. Sie glaubten zuerst, dass die Festplatten zu langsam für die Last waren, also bereiteten sie einen Wechsel zu einem schnelleren Festplattentyp vor. Um 09:01 Uhr einigte sich das Team auf zwei Workstreams: Verschieben Sie die Server auf schnellere Festplatten und fügen Sie einen zweiten Gen 2-Cluster hinzu, so dass sich die Jobs auf zwei Cluster aufteilen würden. Um 09:41 Uhr fanden Ingenieure die Ursache. Jeder Planungsserver hat schnelle Festplatten direkt an ihn angeschlossen, und der Scheduler soll seine Arbeitsdaten dort halten. Diese Server laufen auf einem sicherheitsgesicherten Betriebssystemabbild, und auf diesem Bild wurden die schnellen Festplatten nicht verwendet. Der Scheduler schrieb seine Daten stattdessen auf langsamere netzwerkgebundene Festplatten. Das Skript, das die schnellen Festplatten einrichtete, scheiterte ohne Fehler, und eine Lücke in der Protokollierung auf diesen Servern versteckte den Fehler. Auch der Gen 2-Verkehr war immer platzender geworden. Die langsameren Scheiben sättigten sich während dieser Bursts, und der Scheduler fiel zurück. Die Wartezeiten erreichten ihren Höhepunkt um 09:54 Uhr, als Jobs in der mittleren Ressourcenklasse Gen 2 bis zu 30 Minuten warteten. Um 09:55 Uhr wandten die Ingenieure einen Fix an, der die schnellen Festplatten korrekt einrichtete. Um 10:11 Uhr begann der Scheduler, Jobs schneller zu platzieren, was bestätigte, dass die Server mit neuen Jobs Schritt halten konnten. Die Wartezeiten für Gen 2 Medium fielen auf 13 Minuten um 10:14, 7 Minuten um 10:17 und 1 Minute 30 Sekunden um 10:20. Wir haben die Statusseite um 10:24 Uhr auf die Überwachung verschoben und den Vorfall um 10:45 Uhr behoben. Um 11:20 Uhr begann der zweite Gen 2-Cluster, Jobs zu erledigen. ### **Oktober 7, 13:27 bis 14:06: Erhöhte Wartezeiten für Maschinenjobs** Wir erklärten einen Vorfall um 13:27 Uhr, nachdem wir erhöhte Warteschlangen und Wartezeiten gesehen hatten. Wir haben auf der Statusseite um 13:31 gepostet. Um 13:31 Uhr sahen die Ingenieure, dass wir Schwierigkeiten hatten, virtuelle Maschinen für Maschinenjobs zu erwerben, und dass die Anzahl der Jobs, die auf den Start warteten, vor allem für Maschinenjobs hoch war. Um 13:34 Uhr wurden die Wartezeiten zwischen den Executoren erhöht. Um 13:48 Uhr begannen sich die Wartezeiten zu erholen, als mehr Maschinen verfügbar wurden, und wir lösten den Vorfall um 14:06 Uhr. ### **Oktober 7, 14:24 bis 15:21: Jobausfälle und Workflow-Verzögerungen** Kurz nachdem der vorherige Vorfall als behoben markiert wurde, erklärten wir um 14:24 Uhr einen neuen Vorfall aufgrund eines starken Rückgangs der Anzahl der in unseren Ausführungssystemen eingereichten Jobs. Um 14:26 Uhr sahen die Ingenieure, dass Pods des Jobkonfigurationsdienstes neu gestartet wurden. Pods, die neu starten, lassen weniger Kopien des Dienstes zurück, um Anfragen zu beantworten, und Jobs, die ihre Konfiguration nicht abrufen konnten, nachdem wiederholte Versuche mit einem Infrastrukturfehler fehlgeschlagen waren. Workflows, die bereits liefen, warteten auf Updates von Jobs, die noch nicht begonnen hatten. Um 14:35 Uhr erhöhten die Ingenieure die Menge an verfügbarem Speicher für die Pods und erhöhten die Anzahl der Pods, was dem Dienst mehr Kopien gab, um die Last zu teilen. Wir haben auch die Menge an verfügbarem Arbeitsspeicher erhöht, mit deren Wiederherstellung begonnen wurde, und die Anzahl der Nachrichten, die durch unser Workflowsystem fließen, ist auf ein normales Niveau zurückgekehrt. Um 14:44 Uhr haben wir die Statusseite zur Überwachung verschoben. Pods im Job-Konfigurationsdienst erreichten ihre Speichergrenzen und starteten neu. Wir haben die Speicherzuweisungen und Pod-Zahlen erhöht und der Dienst wurde wiederhergestellt. Um 15:13 Uhr haben wir die Anzahl der Instanzen in unseren Gen 2 Docker-Clustern erhöht, so dass wir den Rückstand von Warteaufträgen schnell durcharbeiten konnten. Wir haben den Vorfall um 15:21 Uhr gelöst. ### **Oktober 7, 18:49 bis 20:05: Erhöhte Wartezeiten für Docker Gen 2 Jobs** Wir erklärten einen neuen Vorfall um 18:49 Uhr, nachdem die Wartezeiten von Docker Gen 2 gestiegen waren. Um 18:51 Uhr bestätigten die Ingenieure, dass ein Mangel an verfügbaren Instanzen uns davon abhielt, genug davon zu erwerben, was die Wartezeiten erhöhte. Wartezeiten unterschieden sich durch die Größe der Ressourcenklasse. Um 19:52 Uhr waren die durchschnittlichen Wartezeiten niedriger als eine Stunde früher, da mehr Kapazität verfügbar wurde, obwohl kurze Spitzen anhielten, und wir die Statusseite zur Überwachung verschoben haben. Wir haben den Vorfall um 20:05 Uhr gelöst. ### **Oktober 8: Linux-Maschine und Remote-Docker-Jobs warten bis zu 50 Minuten ** Wir erklärten einen Vorfall um 12:48 Uhr, nachdem wir eine große Anzahl von Jobs gesehen hatten, die auf den Start warteten, und lange Wartezeiten für Maschinen- und Remote-Docker-Jobs. Um 12:49 Uhr sahen die Ingenieure, dass unser Cloud-Anbieter nicht genügend Instanzen liefern konnte. Die Verzögerungen stiegen weiter, als wir untersuchten. Um 13:13 Uhr begannen wir, die Logik zu untersuchen, die einen anderen Instanztyp oder eine andere Region auswählt, wenn unsere erste Wahl nicht verfügbar ist. Um 13:24 Uhr vermuteten wir, dass ein Fehler in dieser Logik uns daran hinderte, andere Instanztypen in unserer primären Region zu verwenden, also deaktivierten wir unsere Fallback-Region und bestätigten die Ursache des Fehlers. Ingenieure begannen mit der Arbeit an einem Fix und setzten ihn um 14:49 Uhr ein. Der Dienst begann, andere Instanztypen anzufordern, und startete Maschinen in großer Zahl. Um 14:58 Uhr sank die Warteschlange der Jobs, die auf eine Maschine warteten, stetig. Die durchschnittlichen Wartezeiten in den Ressourcenklassen gingen in der nächsten Stunde weiter zurück, als wir den Rückstand der Wartejobs durcharbeiteten. Um 16:00 Uhr wurde die Warteschlange für Jobs, die auf eine Maschine warteten, gelöscht und die Anzahl der Wartejobs wurde wieder normal. Wir haben die Statusseite um 16:09 Uhr auf die Überwachung verschoben und den Vorfall um 16:35 Uhr behoben. ## **Zukünftige Prävention und Prozessverbesserung** Wir unternehmen die folgenden Schritte, um die Widerstandsfähigkeit von Arbeitsbeginnzeiten zu stärken, einschließlich Angebotsdiversifizierung, Fallback-Logik und Früherkennung. **Wir erweitern unsere Rechenregionen.** In den Vorfällen vom 7. und 8. Oktober konnte unser Cloud-Anbieter nicht genügend Instanzen in den von uns verwendeten Regionen liefern. Wir fügen unserer Fallback-Logik neue Regionen hinzu, um Nachfragespitzen zu bewältigen, die unsere bevorzugten Regionen übertreffen. ** Wir beheben die Logik, die einen anderen Instanztyp auswählt. ** Am 8. Oktober verhinderte ein Defekt, dass der Maschinenbereitstellungsdienst andere Instanztypen in derselben Region verwendete. Wir haben während des Vorfalls einen Fix bereitgestellt und überprüfen und refactoringen nun diese Logik als Ganzes mit Tests, so dass ein Mangel an einem Instanztyp die Arbeit in einen anderen verschiebt. **Wir erweitern die von uns angebotenen Instanztypen und sichern zusätzliche Kapazitäten.** Wir arbeiten mit unserem Cloud-Anbieter zusammen, um zusätzliche Kapazitäten in unseren bestehenden Regionen zu reservieren, und wir fügen Instanztypen hinzu, auf denen Jobs ausgeführt werden können. Die Nachfrage der Industrie nach Hochleistungsrechnern wächst. Wir diversifizieren, wo und wie wir Kapazitäten beziehen, damit unsere Kunden von Angebotsschwankungen isoliert werden. **Wir haben einen zweiten Gen 2 Docker Cluster hinzugefügt, so dass Traffic Bursts auf zwei Cluster verteilt sind. ** Wir fügen auch Benachrichtigungen zur Planung der Server-Festplattensättigung und dazu hinzu, wie schnell der Scheduler Jobs platziert, und eine Warnung, die ausgelöst wird, wenn ein Server ohne seine schnellen Festplatten startet. Wir haben das Disk-Setup-Skript mit einem Fehler fehlgeschlagen, und wir haben den Protokollversand von diesen Servern wiederhergestellt, so dass ein ähnliches Problem früher sichtbar ist. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Wir danken unseren Kunden für ihre Geduld, während unser Team daran arbeitete, diese Vorfälle zu lösen. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 14:27 UTCinvestigating

   Wir untersuchen einen Anstieg der Infra-Fails für Kundenjobs.

2. 7. Oktober 2026 um 14:44 UTCmonitoring

   Wir sehen Zeichen der Erholung. Die Wartezeiten von Docker Gen2 sind leicht erhöht und wir überwachen.

3. 7. Oktober 2026 um 15:21 UTCresolved

   Dieser Vorfall wurde behoben.

4. 8. Oktober 2026 um 17:55 UTCpostmortem

   ## **Zusammenfassung** Zwischen dem 1. Oktober und dem 8. Oktober 2026 erlebten CircleCI-Kunden fünf separate Vorfälle, bei denen Jobs länger als normal auf den Start warteten oder nicht starteten. Drei der Vorfälle wurden durch die begrenzte Instanzverfügbarkeit von unserem Cloud-Anbieter verursacht. Eines wurde durch ein Konfigurationsproblem in unserer Planungsinfrastruktur und eines durch Speichergrenzen eines internen Dienstes verursacht, die wir während des Vorfalls angesprochen haben. * **Oktober 1, 07:57 bis 10:24 UTC:** Docker Gen 2 Jobs warteten bis zu 30 Minuten, um zu beginnen. Ein Konfigurationsproblem verhinderte, dass die Gen 2-Planungsserver ihre leistungsstarken lokalen Festplatten verwenden konnten. Während eines Verkehrsstoßes sättigten sich die Fallback-Disks und die Jobplatzierung verlangsamte sich. * **Oktober 7, 13:27 bis 14:06 UTC:** Maschinenjobs warteten länger als normal, weil wir nicht genügend virtuelle Maschinen von unserem Cloud-Anbieter erwerben konnten. * **Oktober 7, 14:24 bis 15:21 UTC:** Einige Jobs scheiterten mit einem Infrastrukturfehler, und Workflows verzögerten sich. Der Dienst, der jedem Auftrag seine Konfiguration beim Start gibt, ist aus dem Speicher und wurde neu gestartet. * **Oktober 7, 18:49 bis 20:05 UTC:** Docker Gen 2-Jobs haben länger als normal gewartet, weil wir nicht genügend Instanzen von unserem Cloud-Anbieter erhalten konnten. * **Oktober 8, 12:48 bis 16:00 UTC:** Linux-Maschinenjobs und Remote-Docker-Jobs warteten bis zu 50 Minuten, um zu starten. Unser Cloud-Anbieter hatte nicht genug von dem von uns angeforderten Instanztyp, und ein Fehler in der Logik, die einen anderen Instanztyp auswählt, hinderte uns daran, Alternativen zu verwenden. Jobs, die während dieser Vorfälle warteten, wurden verzögert, nicht verloren. Kunden, deren Jobs mit einem Infrastrukturfehler während des Vorfalls vom 7. Oktober von 14:24 bis 15:21 UTC gescheitert sind, können sie erneut ausführen. Die ursprünglichen Statusseiten finden Sie unten: * [Oktober 1 - Verzögert den Start von Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [Oktober 7 - Verzögerung beim Starten von Machine Job Tasks](https://status.circleci.com/incidents/tj6wdnfjwr64) * [7. Oktober - Erhöhte Infra-Ausfälle bei Kundenjobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [7. Oktober - Erhöhte Aufgabenwartezeiten für Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [Oktober 8 - Erhöhte Wartezeiten für Maschinenaufträge](https://status.circleci.com/incidents/jn756xtsy4xg) ## **Hintergrund ** Jeder Job, der auf CircleCI läuft, muss berechnet werden. Woher dieser Compute kommt, hängt vom Executor ab. Docker-Jobs laufen auf Clustern von Servern, die die Arbeit für eine Flotte von Instanzen planen. Der Scheduler ist die Software auf diesen Servern, die entscheidet, welche Instanz jeden Job ausführt. Gen 2 Docker Jobs liefen auf einem solchen Cluster zum Zeitpunkt des Vorfalls vom 1. Oktober. Gen 1 Docker Jobs sind auf mehrere Cluster verteilt. Maschinenjobs, einschließlich Remote-Docker-Jobs, erhalten eine dedizierte virtuelle Maschine. Ein Remote-Docker-Job wird als Linux-Maschinenjob von der Einreichung bis zur Bereitstellung bearbeitet. Unser Maschinenbereitstellungsservice fordert jede Maschine von unserem Cloud-Anbieter in einer der beiden Regionen an, die wir normalerweise für Maschinenaufträge verwenden. Wenn der Anbieter den von uns angeforderten Instanztyp nicht bereitstellen kann, greift der Dienst zurück: Er fordert einen anderen Instanztyp oder eine andere Region aus einer von uns verwalteten Liste an. Ein Job wartet, bis eine Maschine verfügbar ist. Wenn ein Job beginnt, fragt er einen Jobkonfigurationsdienst nach seiner Konfiguration. Dieser Dienst läuft als eine Reihe von Pods, die kleine Kopien des gleichen Programms sind. Wenn zu viele Pods aufhören, tragen die verbleibenden Pods mehr Last und Jobs können nicht beginnen, bis sich der Dienst erholt hat. Diese Pfade hängen von drei Arten von Kapazitäten ab: dem Durchsatz unserer Scheduling-Systeme, der Bereitstellung von Instanzen von unserem Cloud-Anbieter und dem Speicher und der Anzahl der Kopien der Dienste, die Jobs starten. Ein Defizit in einem von ihnen lässt Jobs warten oder scheitern. ## **Was geschah ** \(Alle Zeiten UTC\) ### **Oktober 1: Docker Gen 2 Jobs verspätet sich bis zu 30 Minuten ** Um 07:44 Uhr stieg die Festplattenaktivität auf den Servern, die Gen 2 Docker-Jobs planen, auf 90% der Kapazität und blieb dort. Um 07:57 Uhr begann die Zahl der Docker-Jobs, die auf den Start warteten, zu wachsen, und die Wartezeiten stiegen damit. Eine automatisierte Benachrichtigung hat den Bereitschaftstechniker um 08:08 Uhr auf die Seite gebracht. Wir erklärten einen Vorfall um 08:42. Um 08:43 Uhr identifizierten die Ingenieure eine hohe Latenz auf den Planungsservern. Sie glaubten zuerst, dass die Festplatten zu langsam für die Last waren, also bereiteten sie einen Wechsel zu einem schnelleren Festplattentyp vor. Um 09:01 Uhr einigte sich das Team auf zwei Workstreams: Verschieben Sie die Server auf schnellere Festplatten und fügen Sie einen zweiten Gen 2-Cluster hinzu, so dass sich die Jobs auf zwei Cluster aufteilen würden. Um 09:41 Uhr fanden Ingenieure die Ursache. Jeder Planungsserver hat schnelle Festplatten direkt an ihn angeschlossen, und der Scheduler soll seine Arbeitsdaten dort halten. Diese Server laufen auf einem sicherheitsgesicherten Betriebssystemabbild, und auf diesem Bild wurden die schnellen Festplatten nicht verwendet. Der Scheduler schrieb seine Daten stattdessen auf langsamere netzwerkgebundene Festplatten. Das Skript, das die schnellen Festplatten einrichtete, scheiterte ohne Fehler, und eine Lücke in der Protokollierung auf diesen Servern versteckte den Fehler. Auch der Gen 2-Verkehr war immer platzender geworden. Die langsameren Scheiben sättigten sich während dieser Bursts, und der Scheduler fiel zurück. Die Wartezeiten erreichten ihren Höhepunkt um 09:54 Uhr, als Jobs in der mittleren Ressourcenklasse Gen 2 bis zu 30 Minuten warteten. Um 09:55 Uhr wandten die Ingenieure einen Fix an, der die schnellen Festplatten korrekt einrichtete. Um 10:11 Uhr begann der Scheduler, Jobs schneller zu platzieren, was bestätigte, dass die Server mit neuen Jobs Schritt halten konnten. Die Wartezeiten für Gen 2 Medium fielen auf 13 Minuten um 10:14, 7 Minuten um 10:17 und 1 Minute 30 Sekunden um 10:20. Wir haben die Statusseite um 10:24 Uhr auf die Überwachung verschoben und den Vorfall um 10:45 Uhr behoben. Um 11:20 Uhr begann der zweite Gen 2-Cluster, Jobs zu erledigen. ### **Oktober 7, 13:27 bis 14:06: Erhöhte Wartezeiten für Maschinenjobs** Wir erklärten einen Vorfall um 13:27 Uhr, nachdem wir erhöhte Warteschlangen und Wartezeiten gesehen hatten. Wir haben auf der Statusseite um 13:31 gepostet. Um 13:31 Uhr sahen die Ingenieure, dass wir Schwierigkeiten hatten, virtuelle Maschinen für Maschinenjobs zu erwerben, und dass die Anzahl der Jobs, die auf den Start warteten, vor allem für Maschinenjobs hoch war. Um 13:34 Uhr wurden die Wartezeiten zwischen den Executoren erhöht. Um 13:48 Uhr begannen sich die Wartezeiten zu erholen, als mehr Maschinen verfügbar wurden, und wir lösten den Vorfall um 14:06 Uhr. ### **Oktober 7, 14:24 bis 15:21: Jobausfälle und Workflow-Verzögerungen** Kurz nachdem der vorherige Vorfall als behoben markiert wurde, erklärten wir um 14:24 Uhr einen neuen Vorfall aufgrund eines starken Rückgangs der Anzahl der in unseren Ausführungssystemen eingereichten Jobs. Um 14:26 Uhr sahen die Ingenieure, dass Pods des Jobkonfigurationsdienstes neu gestartet wurden. Pods, die neu starten, lassen weniger Kopien des Dienstes zurück, um Anfragen zu beantworten, und Jobs, die ihre Konfiguration nicht abrufen konnten, nachdem wiederholte Versuche mit einem Infrastrukturfehler fehlgeschlagen waren. Workflows, die bereits liefen, warteten auf Updates von Jobs, die noch nicht begonnen hatten. Um 14:35 Uhr erhöhten die Ingenieure die Menge an verfügbarem Speicher für die Pods und erhöhten die Anzahl der Pods, was dem Dienst mehr Kopien gab, um die Last zu teilen. Wir haben auch die Menge an verfügbarem Arbeitsspeicher erhöht, mit deren Wiederherstellung begonnen wurde, und die Anzahl der Nachrichten, die durch unser Workflowsystem fließen, ist auf ein normales Niveau zurückgekehrt. Um 14:44 Uhr haben wir die Statusseite zur Überwachung verschoben. Pods im Job-Konfigurationsdienst erreichten ihre Speichergrenzen und starteten neu. Wir haben die Speicherzuweisungen und Pod-Zahlen erhöht und der Dienst wurde wiederhergestellt. Um 15:13 Uhr haben wir die Anzahl der Instanzen in unseren Gen 2 Docker-Clustern erhöht, so dass wir den Rückstand von Warteaufträgen schnell durcharbeiten konnten. Wir haben den Vorfall um 15:21 Uhr gelöst. ### **Oktober 7, 18:49 bis 20:05: Erhöhte Wartezeiten für Docker Gen 2 Jobs** Wir erklärten einen neuen Vorfall um 18:49 Uhr, nachdem die Wartezeiten von Docker Gen 2 gestiegen waren. Um 18:51 Uhr bestätigten die Ingenieure, dass ein Mangel an verfügbaren Instanzen uns davon abhielt, genug davon zu erwerben, was die Wartezeiten erhöhte. Wartezeiten unterschieden sich durch die Größe der Ressourcenklasse. Um 19:52 Uhr waren die durchschnittlichen Wartezeiten niedriger als eine Stunde früher, da mehr Kapazität verfügbar wurde, obwohl kurze Spitzen anhielten, und wir die Statusseite zur Überwachung verschoben haben. Wir haben den Vorfall um 20:05 Uhr gelöst. ### **Oktober 8: Linux-Maschine und Remote-Docker-Jobs warten bis zu 50 Minuten ** Wir erklärten einen Vorfall um 12:48 Uhr, nachdem wir eine große Anzahl von Jobs gesehen hatten, die auf den Start warteten, und lange Wartezeiten für Maschinen- und Remote-Docker-Jobs. Um 12:49 Uhr sahen die Ingenieure, dass unser Cloud-Anbieter nicht genügend Instanzen liefern konnte. Die Verzögerungen stiegen weiter, als wir untersuchten. Um 13:13 Uhr begannen wir, die Logik zu untersuchen, die einen anderen Instanztyp oder eine andere Region auswählt, wenn unsere erste Wahl nicht verfügbar ist. Um 13:24 Uhr vermuteten wir, dass ein Fehler in dieser Logik uns daran hinderte, andere Instanztypen in unserer primären Region zu verwenden, also deaktivierten wir unsere Fallback-Region und bestätigten die Ursache des Fehlers. Ingenieure begannen mit der Arbeit an einem Fix und setzten ihn um 14:49 Uhr ein. Der Dienst begann, andere Instanztypen anzufordern, und startete Maschinen in großer Zahl. Um 14:58 Uhr sank die Warteschlange der Jobs, die auf eine Maschine warteten, stetig. Die durchschnittlichen Wartezeiten in den Ressourcenklassen gingen in der nächsten Stunde weiter zurück, als wir den Rückstand der Wartejobs durcharbeiteten. Um 16:00 Uhr wurde die Warteschlange für Jobs, die auf eine Maschine warteten, gelöscht und die Anzahl der Wartejobs wurde wieder normal. Wir haben die Statusseite um 16:09 Uhr auf die Überwachung verschoben und den Vorfall um 16:35 Uhr behoben. ## **Zukünftige Prävention und Prozessverbesserung** Wir unternehmen die folgenden Schritte, um die Widerstandsfähigkeit von Arbeitsbeginnzeiten zu stärken, einschließlich Angebotsdiversifizierung, Fallback-Logik und Früherkennung. **Wir erweitern unsere Rechenregionen.** In den Vorfällen vom 7. und 8. Oktober konnte unser Cloud-Anbieter nicht genügend Instanzen in den von uns verwendeten Regionen liefern. Wir fügen unserer Fallback-Logik neue Regionen hinzu, um Nachfragespitzen zu bewältigen, die unsere bevorzugten Regionen übertreffen. ** Wir beheben die Logik, die einen anderen Instanztyp auswählt. ** Am 8. Oktober verhinderte ein Defekt, dass der Maschinenbereitstellungsdienst andere Instanztypen in derselben Region verwendete. Wir haben während des Vorfalls einen Fix bereitgestellt und überprüfen und refactoringen nun diese Logik als Ganzes mit Tests, so dass ein Mangel an einem Instanztyp die Arbeit in einen anderen verschiebt. **Wir erweitern die von uns angebotenen Instanztypen und sichern zusätzliche Kapazitäten.** Wir arbeiten mit unserem Cloud-Anbieter zusammen, um zusätzliche Kapazitäten in unseren bestehenden Regionen zu reservieren, und wir fügen Instanztypen hinzu, auf denen Jobs ausgeführt werden können. Die Nachfrage der Industrie nach Hochleistungsrechnern wächst. Wir diversifizieren, wo und wie wir Kapazitäten beziehen, damit unsere Kunden von Angebotsschwankungen isoliert werden. **Wir haben einen zweiten Gen 2 Docker Cluster hinzugefügt, so dass Traffic Bursts auf zwei Cluster verteilt sind. ** Wir fügen auch Benachrichtigungen zur Planung der Server-Festplattensättigung und dazu hinzu, wie schnell der Scheduler Jobs platziert, und eine Warnung, die ausgelöst wird, wenn ein Server ohne seine schnellen Festplatten startet. Wir haben das Disk-Setup-Skript mit einem Fehler fehlgeschlagen, und wir haben den Protokollversand von diesen Servern wiederhergestellt, so dass ein ähnliches Problem früher sichtbar ist. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Wir danken unseren Kunden für ihre Geduld, während unser Team daran arbeitete, diese Vorfälle zu lösen. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 13:40 UTCinvestigating

   Kunden können erhöhte Wartezeiten für Machine Job Tasks erleben, wir untersuchen die Ursache und werden aktualisiert, wenn wir mehr wissen.

2. 7. Oktober 2026 um 13:52 UTCmonitoring

   Wir sehen Zeichen der Erholung und der Überwachung der Situation.

3. 7. Oktober 2026 um 14:06 UTCresolved

   Der Vorfall wurde behoben. Vielen Dank für Ihre Geduld

4. 8. Oktober 2026 um 17:55 UTCpostmortem

   ## **Zusammenfassung** Zwischen dem 1. Oktober und dem 8. Oktober 2026 erlebten CircleCI-Kunden fünf separate Vorfälle, bei denen Jobs länger als normal auf den Start warteten oder nicht starteten. Drei der Vorfälle wurden durch die begrenzte Instanzverfügbarkeit von unserem Cloud-Anbieter verursacht. Eines wurde durch ein Konfigurationsproblem in unserer Planungsinfrastruktur und eines durch Speichergrenzen eines internen Dienstes verursacht, die wir während des Vorfalls angesprochen haben. * **Oktober 1, 07:57 bis 10:24 UTC:** Docker Gen 2 Jobs warteten bis zu 30 Minuten, um zu beginnen. Ein Konfigurationsproblem verhinderte, dass die Gen 2-Planungsserver ihre leistungsstarken lokalen Festplatten verwenden konnten. Während eines Verkehrsstoßes sättigten sich die Fallback-Disks und die Jobplatzierung verlangsamte sich. * **Oktober 7, 13:27 bis 14:06 UTC:** Maschinenjobs warteten länger als normal, weil wir nicht genügend virtuelle Maschinen von unserem Cloud-Anbieter erwerben konnten. * **Oktober 7, 14:24 bis 15:21 UTC:** Einige Jobs scheiterten mit einem Infrastrukturfehler, und Workflows verzögerten sich. Der Dienst, der jedem Auftrag seine Konfiguration beim Start gibt, ist aus dem Speicher und wurde neu gestartet. * **Oktober 7, 18:49 bis 20:05 UTC:** Docker Gen 2-Jobs haben länger als normal gewartet, weil wir nicht genügend Instanzen von unserem Cloud-Anbieter erhalten konnten. * **Oktober 8, 12:48 bis 16:00 UTC:** Linux-Maschinenjobs und Remote-Docker-Jobs warteten bis zu 50 Minuten, um zu starten. Unser Cloud-Anbieter hatte nicht genug von dem von uns angeforderten Instanztyp, und ein Fehler in der Logik, die einen anderen Instanztyp auswählt, hinderte uns daran, Alternativen zu verwenden. Jobs, die während dieser Vorfälle warteten, wurden verzögert, nicht verloren. Kunden, deren Jobs mit einem Infrastrukturfehler während des Vorfalls vom 7. Oktober von 14:24 bis 15:21 UTC gescheitert sind, können sie erneut ausführen. Die ursprünglichen Statusseiten finden Sie unten: * [Oktober 1 - Verzögert den Start von Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [Oktober 7 - Verzögerung beim Starten von Machine Job Tasks](https://status.circleci.com/incidents/tj6wdnfjwr64) * [7. Oktober - Erhöhte Infra-Ausfälle bei Kundenjobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [7. Oktober - Erhöhte Aufgabenwartezeiten für Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [Oktober 8 - Erhöhte Wartezeiten für Maschinenaufträge](https://status.circleci.com/incidents/jn756xtsy4xg) ## **Hintergrund ** Jeder Job, der auf CircleCI läuft, muss berechnet werden. Woher dieser Compute kommt, hängt vom Executor ab. Docker-Jobs laufen auf Clustern von Servern, die die Arbeit für eine Flotte von Instanzen planen. Der Scheduler ist die Software auf diesen Servern, die entscheidet, welche Instanz jeden Job ausführt. Gen 2 Docker Jobs liefen auf einem solchen Cluster zum Zeitpunkt des Vorfalls vom 1. Oktober. Gen 1 Docker Jobs sind auf mehrere Cluster verteilt. Maschinenjobs, einschließlich Remote-Docker-Jobs, erhalten eine dedizierte virtuelle Maschine. Ein Remote-Docker-Job wird als Linux-Maschinenjob von der Einreichung bis zur Bereitstellung bearbeitet. Unser Maschinenbereitstellungsservice fordert jede Maschine von unserem Cloud-Anbieter in einer der beiden Regionen an, die wir normalerweise für Maschinenaufträge verwenden. Wenn der Anbieter den von uns angeforderten Instanztyp nicht bereitstellen kann, greift der Dienst zurück: Er fordert einen anderen Instanztyp oder eine andere Region aus einer von uns verwalteten Liste an. Ein Job wartet, bis eine Maschine verfügbar ist. Wenn ein Job beginnt, fragt er einen Jobkonfigurationsdienst nach seiner Konfiguration. Dieser Dienst läuft als eine Reihe von Pods, die kleine Kopien des gleichen Programms sind. Wenn zu viele Pods aufhören, tragen die verbleibenden Pods mehr Last und Jobs können nicht beginnen, bis sich der Dienst erholt hat. Diese Pfade hängen von drei Arten von Kapazitäten ab: dem Durchsatz unserer Scheduling-Systeme, der Bereitstellung von Instanzen von unserem Cloud-Anbieter und dem Speicher und der Anzahl der Kopien der Dienste, die Jobs starten. Ein Defizit in einem von ihnen lässt Jobs warten oder scheitern. ## **Was geschah ** \(Alle Zeiten UTC\) ### **Oktober 1: Docker Gen 2 Jobs verspätet sich bis zu 30 Minuten ** Um 07:44 Uhr stieg die Festplattenaktivität auf den Servern, die Gen 2 Docker-Jobs planen, auf 90% der Kapazität und blieb dort. Um 07:57 Uhr begann die Zahl der Docker-Jobs, die auf den Start warteten, zu wachsen, und die Wartezeiten stiegen damit. Eine automatisierte Benachrichtigung hat den Bereitschaftstechniker um 08:08 Uhr auf die Seite gebracht. Wir erklärten einen Vorfall um 08:42. Um 08:43 Uhr identifizierten die Ingenieure eine hohe Latenz auf den Planungsservern. Sie glaubten zuerst, dass die Festplatten zu langsam für die Last waren, also bereiteten sie einen Wechsel zu einem schnelleren Festplattentyp vor. Um 09:01 Uhr einigte sich das Team auf zwei Workstreams: Verschieben Sie die Server auf schnellere Festplatten und fügen Sie einen zweiten Gen 2-Cluster hinzu, so dass sich die Jobs auf zwei Cluster aufteilen würden. Um 09:41 Uhr fanden Ingenieure die Ursache. Jeder Planungsserver hat schnelle Festplatten direkt an ihn angeschlossen, und der Scheduler soll seine Arbeitsdaten dort halten. Diese Server laufen auf einem sicherheitsgesicherten Betriebssystemabbild, und auf diesem Bild wurden die schnellen Festplatten nicht verwendet. Der Scheduler schrieb seine Daten stattdessen auf langsamere netzwerkgebundene Festplatten. Das Skript, das die schnellen Festplatten einrichtete, scheiterte ohne Fehler, und eine Lücke in der Protokollierung auf diesen Servern versteckte den Fehler. Auch der Gen 2-Verkehr war immer platzender geworden. Die langsameren Scheiben sättigten sich während dieser Bursts, und der Scheduler fiel zurück. Die Wartezeiten erreichten ihren Höhepunkt um 09:54 Uhr, als Jobs in der mittleren Ressourcenklasse Gen 2 bis zu 30 Minuten warteten. Um 09:55 Uhr wandten die Ingenieure einen Fix an, der die schnellen Festplatten korrekt einrichtete. Um 10:11 Uhr begann der Scheduler, Jobs schneller zu platzieren, was bestätigte, dass die Server mit neuen Jobs Schritt halten konnten. Die Wartezeiten für Gen 2 Medium fielen auf 13 Minuten um 10:14, 7 Minuten um 10:17 und 1 Minute 30 Sekunden um 10:20. Wir haben die Statusseite um 10:24 Uhr auf die Überwachung verschoben und den Vorfall um 10:45 Uhr behoben. Um 11:20 Uhr begann der zweite Gen 2-Cluster, Jobs zu erledigen. ### **Oktober 7, 13:27 bis 14:06: Erhöhte Wartezeiten für Maschinenjobs** Wir erklärten einen Vorfall um 13:27 Uhr, nachdem wir erhöhte Warteschlangen und Wartezeiten gesehen hatten. Wir haben auf der Statusseite um 13:31 gepostet. Um 13:31 Uhr sahen die Ingenieure, dass wir Schwierigkeiten hatten, virtuelle Maschinen für Maschinenjobs zu erwerben, und dass die Anzahl der Jobs, die auf den Start warteten, vor allem für Maschinenjobs hoch war. Um 13:34 Uhr wurden die Wartezeiten zwischen den Executoren erhöht. Um 13:48 Uhr begannen sich die Wartezeiten zu erholen, als mehr Maschinen verfügbar wurden, und wir lösten den Vorfall um 14:06 Uhr. ### **Oktober 7, 14:24 bis 15:21: Jobausfälle und Workflow-Verzögerungen** Kurz nachdem der vorherige Vorfall als behoben markiert wurde, erklärten wir um 14:24 Uhr einen neuen Vorfall aufgrund eines starken Rückgangs der Anzahl der in unseren Ausführungssystemen eingereichten Jobs. Um 14:26 Uhr sahen die Ingenieure, dass Pods des Jobkonfigurationsdienstes neu gestartet wurden. Pods, die neu starten, lassen weniger Kopien des Dienstes zurück, um Anfragen zu beantworten, und Jobs, die ihre Konfiguration nicht abrufen konnten, nachdem wiederholte Versuche mit einem Infrastrukturfehler fehlgeschlagen waren. Workflows, die bereits liefen, warteten auf Updates von Jobs, die noch nicht begonnen hatten. Um 14:35 Uhr erhöhten die Ingenieure die Menge an verfügbarem Speicher für die Pods und erhöhten die Anzahl der Pods, was dem Dienst mehr Kopien gab, um die Last zu teilen. Wir haben auch die Menge an verfügbarem Arbeitsspeicher erhöht, mit deren Wiederherstellung begonnen wurde, und die Anzahl der Nachrichten, die durch unser Workflowsystem fließen, ist auf ein normales Niveau zurückgekehrt. Um 14:44 Uhr haben wir die Statusseite zur Überwachung verschoben. Pods im Job-Konfigurationsdienst erreichten ihre Speichergrenzen und starteten neu. Wir haben die Speicherzuweisungen und Pod-Zahlen erhöht und der Dienst wurde wiederhergestellt. Um 15:13 Uhr haben wir die Anzahl der Instanzen in unseren Gen 2 Docker-Clustern erhöht, so dass wir den Rückstand von Warteaufträgen schnell durcharbeiten konnten. Wir haben den Vorfall um 15:21 Uhr gelöst. ### **Oktober 7, 18:49 bis 20:05: Erhöhte Wartezeiten für Docker Gen 2 Jobs** Wir erklärten einen neuen Vorfall um 18:49 Uhr, nachdem die Wartezeiten von Docker Gen 2 gestiegen waren. Um 18:51 Uhr bestätigten die Ingenieure, dass ein Mangel an verfügbaren Instanzen uns davon abhielt, genug davon zu erwerben, was die Wartezeiten erhöhte. Wartezeiten unterschieden sich durch die Größe der Ressourcenklasse. Um 19:52 Uhr waren die durchschnittlichen Wartezeiten niedriger als eine Stunde früher, da mehr Kapazität verfügbar wurde, obwohl kurze Spitzen anhielten, und wir die Statusseite zur Überwachung verschoben haben. Wir haben den Vorfall um 20:05 Uhr gelöst. ### **Oktober 8: Linux-Maschine und Remote-Docker-Jobs warten bis zu 50 Minuten ** Wir erklärten einen Vorfall um 12:48 Uhr, nachdem wir eine große Anzahl von Jobs gesehen hatten, die auf den Start warteten, und lange Wartezeiten für Maschinen- und Remote-Docker-Jobs. Um 12:49 Uhr sahen die Ingenieure, dass unser Cloud-Anbieter nicht genügend Instanzen liefern konnte. Die Verzögerungen stiegen weiter, als wir untersuchten. Um 13:13 Uhr begannen wir, die Logik zu untersuchen, die einen anderen Instanztyp oder eine andere Region auswählt, wenn unsere erste Wahl nicht verfügbar ist. Um 13:24 Uhr vermuteten wir, dass ein Fehler in dieser Logik uns daran hinderte, andere Instanztypen in unserer primären Region zu verwenden, also deaktivierten wir unsere Fallback-Region und bestätigten die Ursache des Fehlers. Ingenieure begannen mit der Arbeit an einem Fix und setzten ihn um 14:49 Uhr ein. Der Dienst begann, andere Instanztypen anzufordern, und startete Maschinen in großer Zahl. Um 14:58 Uhr sank die Warteschlange der Jobs, die auf eine Maschine warteten, stetig. Die durchschnittlichen Wartezeiten in den Ressourcenklassen gingen in der nächsten Stunde weiter zurück, als wir den Rückstand der Wartejobs durcharbeiteten. Um 16:00 Uhr wurde die Warteschlange für Jobs, die auf eine Maschine warteten, gelöscht und die Anzahl der Wartejobs wurde wieder normal. Wir haben die Statusseite um 16:09 Uhr auf die Überwachung verschoben und den Vorfall um 16:35 Uhr behoben. ## **Zukünftige Prävention und Prozessverbesserung** Wir unternehmen die folgenden Schritte, um die Widerstandsfähigkeit von Arbeitsbeginnzeiten zu stärken, einschließlich Angebotsdiversifizierung, Fallback-Logik und Früherkennung. **Wir erweitern unsere Rechenregionen.** In den Vorfällen vom 7. und 8. Oktober konnte unser Cloud-Anbieter nicht genügend Instanzen in den von uns verwendeten Regionen liefern. Wir fügen unserer Fallback-Logik neue Regionen hinzu, um Nachfragespitzen zu bewältigen, die unsere bevorzugten Regionen übertreffen. ** Wir beheben die Logik, die einen anderen Instanztyp auswählt. ** Am 8. Oktober verhinderte ein Defekt, dass der Maschinenbereitstellungsdienst andere Instanztypen in derselben Region verwendete. Wir haben während des Vorfalls einen Fix bereitgestellt und überprüfen und refactoringen nun diese Logik als Ganzes mit Tests, so dass ein Mangel an einem Instanztyp die Arbeit in einen anderen verschiebt. **Wir erweitern die von uns angebotenen Instanztypen und sichern zusätzliche Kapazitäten.** Wir arbeiten mit unserem Cloud-Anbieter zusammen, um zusätzliche Kapazitäten in unseren bestehenden Regionen zu reservieren, und wir fügen Instanztypen hinzu, auf denen Jobs ausgeführt werden können. Die Nachfrage der Industrie nach Hochleistungsrechnern wächst. Wir diversifizieren, wo und wie wir Kapazitäten beziehen, damit unsere Kunden von Angebotsschwankungen isoliert werden. **Wir haben einen zweiten Gen 2 Docker Cluster hinzugefügt, so dass Traffic Bursts auf zwei Cluster verteilt sind. ** Wir fügen auch Benachrichtigungen zur Planung der Server-Festplattensättigung und dazu hinzu, wie schnell der Scheduler Jobs platziert, und eine Warnung, die ausgelöst wird, wenn ein Server ohne seine schnellen Festplatten startet. Wir haben das Disk-Setup-Skript mit einem Fehler fehlgeschlagen, und wir haben den Protokollversand von diesen Servern wiederhergestellt, so dass ein ähnliches Problem früher sichtbar ist. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Wir danken unseren Kunden für ihre Geduld, während unser Team daran arbeitete, diese Vorfälle zu lösen. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 16:00 UTCinvestigating

   Was ist betroffen Kunden, die CircleCI-Pipelines und Workflows verwenden, einschließlich der Anzeige von UI-Daten, ausgehender Benachrichtigungen und ausgehender Webhooks. Was können Sie erwarten Verzögerungen bei der Erstellung von Pipelines und beim Start von Workflows und Jobs. Job-, Workflow- und Pipeline-Daten können bis zu 15 Minuten in der Benutzeroberfläche erscheinen. Outbound-Benachrichtigungen und Webhooks werden um bis zu 1 Minute verzögert. Nächstes Update Wir werden innerhalb von 30 minuten ein weiteres update bereitstellen oder da wir weitere informationen teilen müssen.

2. 6. Oktober 2026 um 16:10 UTCinvestigating

   Seit 15:47 UTC können Kunden auch gescheiterte Jobs sehen, zusätzlich zu den zuvor gemeldeten Verzögerungen. Unsere Ingenieure untersuchen und mildern das Problem weiter.

3. 6. Oktober 2026 um 16:31 UTCidentified

   Ab 16:02 UTC scheitern Pipelines vollständig, so dass zu diesem Zeitpunkt keine neuen Workflows oder Jobs ausgeführt werden. Dies ist zusätzlich zu den Verzögerungen und gescheiterten Jobs, die zuvor gemeldet wurden. Unsere Ingenieure arbeiten weiterhin daran, das Problem zu mildern, und wir werden weitere Informationen teilen, sobald wir sie haben.

4. 6. Oktober 2026 um 16:42 UTCidentified

   Ab 16:39 UTC beginnen wir, die Erholung für neue Pipelines und Workflows zu sehen, und die Jobs beginnen wieder zu laufen. Unsere Ingenieure arbeiten weiter an der Wiederherstellung und werden weitere Informationen teilen, sobald wir sie haben.

5. 6. Oktober 2026 um 17:21 UTCidentified

   Während Pipelines, Workflows und Jobs wieder laufen, können Kunden länger als üblich Verzögerungen zwischen Jobs in einem Workflow sehen, und ausgehende Benachrichtigungen werden um etwa 1 Minute verzögert. Benachrichtigungen und Statusupdates für Ihr Versionskontrollsystem beginnen wieder zu erlöschen. Unsere Ingenieure arbeiten weiterhin auf eine vollständige Erholung hin.

6. 6. Oktober 2026 um 18:04 UTCidentified

   Kunden erleben länger als üblich Verzögerungen zwischen Jobs in einem Workflow sowie Verzögerungen bei ausgehenden Benachrichtigungen. Wir danken Ihnen für Ihre Geduld, während unsere Ingenieure das Problem weiter untersuchen und daran arbeiten. Wir werden innerhalb der nächsten 30 Minuten ein weiteres Update teilen, oder früher, wenn weitere Informationen verfügbar sind.

7. 6. Oktober 2026 um 18:55 UTCidentified

   Kunden erleben weiterhin längere Verzögerungen als üblich, bevor Workflows und Jobs beginnen, in einigen Fällen bis zu etwa 30 Minuten. Dies wird von früher in dem Vorfall verbessert, aber Verzögerungen bleiben. Verzögerungen bei ausgehenden Benachrichtigungen haben sich verbessert. Wir danken Ihnen für Ihre Geduld, während unsere Ingenieure weiterhin daran arbeiten, die normalen Arbeitsbeginnzeiten wiederherzustellen. Wir werden innerhalb der nächsten 30 Minuten ein weiteres Update teilen, oder früher, wenn weitere Informationen verfügbar sind.

8. 6. Oktober 2026 um 19:16 UTCidentified

   Kunden erleben weiterhin Verzögerungen. Die meisten beginnen jetzt innerhalb von etwa 20 Minuten, verbessert von etwa 40 Minuten früher in dem Vorfall. Eine sehr kleine Anzahl von Workflows hat möglicherweise mehr als 1 Stunde gewartet. Unsere Ingenieure haben Änderungen vorgenommen, die die Servicestabilität verbessert haben, und die verbleibende Verzögerung ist auf einen Arbeitsrückstand zurückzuführen, der sich während des Vorfalls aufgebaut hat. Der Rückstand nimmt ab und wir konzentrieren uns darauf, ihn schneller zu beseitigen. Wir werden mehr Informationen austauschen, wenn der Fortschritt weitergeht. Wir danken Ihnen für Ihre Geduld, während unsere Ingenieure den Rückstand durcharbeiten. Wir werden innerhalb der nächsten 30 Minuten ein weiteres Update teilen, oder früher, wenn weitere Informationen verfügbar sind.

9. 6. Oktober 2026 um 19:51 UTCidentified

   Verzögerungen beim Start von Workflows und Jobs nehmen weiter ab. Die meisten beginnen jetzt innerhalb von etwa 10 Minuten, verbessert von etwa 40 Minuten früher in dem Vorfall. Eine sehr kleine Anzahl von Workflows hat möglicherweise mehr als 1 Stunde gewartet. Wenn Ihr Job nicht gestartet wurde, führen Sie den Job bitte erneut durch. Verzögerungen bei ausgehenden Benachrichtigungen haben sich verbessert. Die verbleibende Verzögerung ist auf einen Arbeitsrückstand zurückzuführen, der sich während des Vorfalls aufgebaut hat und der sich um mehr als die Hälfte verringert hat. Wir erwarten, dass der Rückstand in ca. 15 Minuten behoben wird. Wir werden ein weiteres Update teilen, sobald es gelöscht wurde, oder spätestens innerhalb der nächsten 30 Minuten.

10. 6. Oktober 2026 um 20:13 UTCidentified

    Der Rückstand bei verspäteten Arbeiten wurde behoben, und die Workflows beginnen wieder ohne Verzögerungen bei Benachrichtigungen. Kunden, die Docker- und Linux-Jobs über mehrere Ressourcenklassen hinweg verwenden, einschließlich mittlerer, großer und 2xgroßer Gen2, können nun sehen, dass Jobs einige Minuten in der Warteschlange warten, bevor sie beginnen. Unsere Ingenieure arbeiten weiter daran, dieses Problem zu mildern. Wenn Ihr Job nicht gestartet wurde, führen Sie den Job bitte erneut durch. Wir danken Ihnen für Ihre Geduld, während unsere Ingenieure daran arbeiten. Wir werden innerhalb der nächsten 30 Minuten ein weiteres Update teilen, oder früher, wenn weitere Informationen verfügbar sind.

11. 6. Oktober 2026 um 20:31 UTCmonitoring

    Workflows und Jobs beginnen normal, und die Wartezeiten für Docker- und Linux-Jobs sind wieder normal. Unsere Ingenieure beobachten dieses Problem weiterhin. Wenn Ihr Job nicht gestartet wurde, führen Sie den Job bitte erneut durch. Wir danken Ihnen für Ihre Geduld, während unsere Ingenieure daran arbeiten. Wir werden innerhalb der nächsten 30 Minuten ein weiteres Update teilen, oder früher, wenn weitere Informationen verfügbar sind.

12. 6. Oktober 2026 um 21:18 UTCresolved

    Zwischen ca. 15:30 UTC und 20:30 UTC am 6. Oktober 2026 erlebten Kunden Verzögerungen und Ausfälle bei Pipelines, Workflows und Jobs. Von ca. 16:02 UTC bis 16:39 UTC scheiterten Pipelines und es konnten keine neuen Workflows oder Jobs starten. Nach der Wiederaufnahme des Service begannen Workflows und Jobs weiterhin mit Verzögerungen bis etwa 20:00 UTC. Die Startzeiten betrugen durchschnittlich bis zu etwa 40 Minuten in ihrem Höhepunkt, und eine sehr kleine Anzahl von Workflows wartete mehr als 1 Stunde. Outbound-Benachrichtigungen und Webhooks verzögerten sich ebenfalls bis etwa 19:00 UTC, typischerweise um etwa eine Minute. Als der Rückstand bei verspäteten Arbeiten abgebaut wurde, setzte der daraus resultierende Anstieg der Nachfrage unsere Ausführungskapazität unter Druck, was zu weiteren Verzögerungen bei Docker- und Linux-Jobs führte. Von ca. 19:45 UTC bis 20:30 UTC warteten diese Jobs in der Warteschlange länger als üblich vor dem Start. An der Spitze, um 20:05 UTC, wartet bis zu etwa 8 Minuten für 2xlarge gen2, 6 Minuten für xlarge gen2 und weniger als 5 Minuten für einige andere Ressourcenklassen. Das Problem wurde behoben und alle betroffenen Funktionen haben sich wieder normalisiert. Kunden, deren Jobs in diesem Fenster fehlgeschlagen sind, können betroffene Jobs erneut ausführen. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat.

13. 7. Oktober 2026 um 22:08 UTCpostmortem

    ## Zusammenfassung Am 6. Oktober 2026, von 15:30 bis 20:30 UTC, erlebten CircleCI-Kunden Verzögerungen beim Erstellen von Pipelines und beim Starten von Workflows und Jobs. Von 15:48 bis 16:38 UTC wurden keine Workflows oder Jobs gestartet, und Pipelines, die von 16:02 UTC ausgelöst wurden, scheiterten. Kürzere, intermittierende Verzögerungen begannen früher, um 13:30 UTC. Daten in der CircleCI-Benutzeroberfläche, Benachrichtigungen und Commit-Statusupdates für Versionskontrollanbieter wurden ebenfalls verzögert. Der Vorfall begann in der Datenbank hinter unserem Workflow-Orchestrierungsservice, der jede Pipeline, jeden Workflow und jeden Job auf CircleCI koordiniert. Die routinemäßige Wartung der größten Tabellen der Datenbank schrieb Transaktionsprotokolle schneller, als die Datenbank sie archivieren konnte, und die Protokolle füllten das für sie vorgesehene Speichervolumen. Um zu verhindern, dass die Datenbank schreibgeschützt wird, haben unsere Ingenieure die Protokolle in das Hauptspeichervolumen der Datenbank verschoben. Dieser Schritt nahm die Datenbank für 50 Minuten offline. Als die Datenbank zurückkam, verarbeitete sie die Arbeit mit etwa der Hälfte ihrer normalen Rate, bis unsere Ingenieure eine Datenbankeinstellung um 18:19 UTC änderten. Wir haben dann den Rückstand durchgearbeitet, und die Startzeiten für den Job wurden um 20:30 UTC wieder normal. Kunden, deren Jobs in diesem Fenster fehlgeschlagen sind, können sie erneut ausführen. Die ursprüngliche Statusseite finden Sie hier (https://status.circleci.com/incidents/z4hbq8h49j8c). ## Hintergrund Wenn Sie eine Pipeline auslösen, übergibt CircleCI sie an einen Workflow-Orchestrierungsdienst. Dieser Service verfolgt den Zustand jedes Workflows und Auftrags, entscheidet, wann jeder Auftrag ausgeführt werden kann, und gibt fertige Aufträge an unsere Ausführungsflotte weiter. Es steuert auch die Jobdaten, die Sie in der Benutzeroberfläche sehen, und die Benachrichtigungen und Commit-Status, die wir senden, wenn die Arbeit beendet ist. Der Orchestrierungsdienst speichert seinen Zustand in einer Datenbank. Die Datenbank schreibt jede Änderung in eine Transaktionsprotokollierung, bevor sie sie anwendet, und bewahrt diese Protokolle auf einem dedizierten Speichervolumen auf. Es archiviert die Protokolle kontinuierlich, so dass es diesen Raum wiederverwenden kann. Wenn die Archivierung zurückfällt und sich das Volumen füllt, hört die Datenbank auf, Schreibvorgänge zu akzeptieren, und keine neue Arbeit kann vorankommen. Die Datenbank führt auch einen periodischen Wartungsprozess (Autovacuums) für jede Tabelle aus, um ihre internen Aufzeichnungen im Laufe der Zeit gültig zu halten. Auf einer sehr großen Tabelle liest dieser Prozess jede Seite der Tabelle und schreibt eine große Menge an Transaktionsprotokollen. ## Was geschah \(Alle Zeiten UTC\) Ab 10:02 Uhr am 6. Oktober hat unsere Überwachung kurzlebige Warnungen über Fehler im Orchestrierungsdienst ausgelöst. Jeder Alarm wurde innerhalb von etwa 15 Minuten von selbst gelöscht. Unsere Ingenieure hatten zuvor ähnliche kurze Warnungen gesehen, und das System zeigte keine anderen Anzeichen von Stress, also folgten sie jedes Mal dem Laufbuch, und jede Warnung wurde von selbst gelöscht und begann auch, die Warnungen weniger empfindlich zu machen. Um 12:40 Uhr, zusammen mit dem regulären Workload, der seine eigenen Transaktionsprotokolle generiert, begann der Wartungsprozess in mehreren der größten Tabellen der Datenbank, zusätzliche Transaktionsprotokolle schneller zu schreiben, als die Datenbank sie archivieren konnte, und das Protokollvolumen begann zu füllen. Um 13:30 Uhr begann der Orchestrierungsdienst zu verlangsamen. Bis 15:30 Uhr dauerten einige Pipelines und Jobs länger, um in kurzen Zeiträumen zu starten. Um 13:35 Uhr alarmierte unsere Überwachung erneut, diesmal neben verwandten Warnungen von mehreren anderen Diensten. Infrastructure Engineers folgten den Alarm-Runbooks und räumten einige der Warnungen auf. Die Warnungen kehrten gegen 14:30 Uhr wieder zurück und nach weiteren Untersuchungen erklärten wir um 14:54 Uhr einen Vorfall. Wir hätten die Kombination von Warnungen früher erkennen sollen, und wir haben unten beschrieben, wie wir das beheben. Nach der Erklärung des Vorfalls verfolgten unsere Ingenieure die Verlangsamung bis zum Wartungsprozess (Anti-Wraparound-Autovakuum). Die Datenbank startet diesen Prozess automatisch neu, wenn er abgebrochen wird, so dass unsere Ingenieure ihre Einstellungen geändert haben, um ihn schneller abzuschließen. Um 15:30 Uhr waren die Verzögerungen kontinuierlich und einige Jobs begannen zu scheitern. Um 15:43 Uhr war das Transaktionsprotokollvolumen fast voll. Wenn es gefüllt würde, würde die Datenbank aufhören, Schreiben zu akzeptieren, und keine Arbeit könnte ausgeführt werden. Unsere Ingenieure beschlossen, die Transaktionsprotokolle auf das Hauptspeichervolumen der Datenbank zu verschieben, das viel freien Speicherplatz hatte. Der Umzug erforderte, dass die Datenbank offline ging, und wir konnten nicht im Voraus vorhersagen, wie lange das dauern würde. Der Umzug begann um 15:47 Uhr. Von 15:48 bis 16:38 Uhr konnte der Orchestrierungsdienst keine Arbeit verarbeiten. Kunden konnten immer noch Pipelines auslösen, aber es wurden keine Workflows oder Jobs gestartet, und ab 16:02 schlugen neu ausgelöste Pipelines fehl. Wir haben um 15:58 Uhr auf unserer Statusseite gepostet und um 16:20 Uhr auf einen großen Ausfall hingewiesen. Während die Datenbank offline war, bereiteten unsere Ingenieure eine Ersatzdatenbank als Fallback vor. Die ursprüngliche Datenbank kam zuerst zurück, also haben wir sie in Betrieb gehalten. Um 16:38 Uhr kam die Datenbank wieder online und die Arbeit begann wieder zu fließen. Da sich Transaktionsprotokolle und reguläre Daten nun den gleichen Speicher teilen, lief die Datenbank langsamer als zuvor. Von 16:38 bis 18:19 Uhr verarbeitete der Orchestrierungsdienst die Arbeit mit etwa der Hälfte seiner normalen Rate, und die Jobs warteten Dutzende von Minuten, bis zu maximal 50 Minuten. Während dieser Zeit musste die Datenbank ihren Bestand an Transaktionsprotokollen archivieren, bevor wir sie in ein dediziertes Volumen zurückverlagern konnten. Wir haben auch mehrere Änderungen an Datenbankparametern untersucht und implementiert, um weitere Wartungsläufe vom Start abzuhalten, und Wege vorbereitet, um die Arbeit beim Erreichen des Dienstes zu reduzieren. Zusammen mit der Ersatzdatenbank haben wir während dieser Zeit auch einen kompletten Stack des Dienstes vorbereitet, so dass wir auf das Risiko eines Datenverlustes umsteigen konnten, und uns gegen diesen Schritt entschieden. Um 18:19 Uhr änderten unsere Ingenieure eine Datenbankeinstellung, um die Zeit zu verkürzen, die jeder Schreibvorgang beim Speichern verbrachte. Die Verarbeitungsgeschwindigkeit erholte sich und der Rückstand begann zu räumen. Um es schneller zu löschen, haben wir Datenbank- und Serverkapazität zu den Systemen hinzugefügt, die Jobs an unsere Ausführungsflotte übergeben. Gegen 19:55 Uhr starteten neue Jobs wieder pünktlich. Der Rückstand erreichte dann unsere Ausführungsflotte. Von 19:49 bis 20:30 Uhr warteten einige Docker-Jobs in größeren Ressourcenklassen bis zu 10 Minuten, um zu starten, während die Kapazität skaliert wurde. Um 20:30 Uhr waren die Startzeiten wieder normal. Wir haben die Statusseite um 20:32 Uhr auf die Überwachung verschoben und den Vorfall um 21:19 Uhr behoben. Etwa 3.500 Arbeitsplätze konnten während des Vorfalls nicht beginnen. Kunden können diese Jobs wiederholen. Wir fanden keine Beweise dafür, dass CircleCI mehr als einmal einen Job hatte. Kunden, die einen Workflow ausgeführt haben, während der ursprüngliche Lauf noch verzögert war, haben möglicherweise beide Läufe abgeschlossen. Jahresplan-Kunden können mit ihrem Account-Team zusammenarbeiten, um die Nutzung zu überprüfen. ## Zukünftige Prävention und Prozessverbesserung Wir unternehmen die folgenden Schritte, um eine Wiederholung zu verhindern und unsere Reaktionszeit zu verbessern: **Wir fügen Warnungen zu den Bedingungen hinzu, die diesen Vorfall verursacht haben. ** Unsere Überwachung fing die Verlangsamung, aber wir hatten keine Warnung, wie voll das Transaktionsprotokollvolumen war oder wie weit die Archivierung zurückgefallen war. Wir fügen Warnungen zu beiden hinzu, zusammen mit Warnungen zur Datenbankwartung, die sie antreibt, damit wir früher handeln können. Wir überprüfen auch alle unsere Warnungen, um sicherzustellen, dass laute oder sensible Warnungen keine echten Probleme verbergen. **Wir stimmen ab, wie der Wartungsprozess \(autovacuum\) in unserer Datenbank abläuft.** Wir betrachten die Häufigkeit und die Aggressivität, mit der die Autovakuums in unserer Datenbank laufen. Wir verfolgen auch die Größe dieser Tische im Laufe der Zeit, so dass sie innerhalb sicherer Grenzen bleiben. **Wir entfernen den Engpass des einzelnen Transaktionsprotokolls. ** Alle Schreibvorgänge des Orchestrierungsdienstes durchlaufen derzeit eine Datenbank und ein Transaktionsprotokoll. Als dieses Protokoll zurückfiel, verlangsamten sich jede Pipeline, jeder Workflow und jede Aufgabe. Wir evaluieren zwei Ansätze: Den Dienst auf mehrere Datenbankinstanzen aufzuteilen, jede mit einer eigenen Transaktionsprotokollierung, und ihn in eine verteilte Datenbank zu verschieben, die so aufgebaut ist, dass sie Schreibvorgänge über viele Knoten verteilt. Jeder Ansatz würde den Effekt eines Backlogs auf einen Teil des Workloads begrenzen. **Wir lassen unsere Systeme darauf warten, dass sich der Orchestrierungsdienst erholt. ** Während des Vorfalls scheiterten einige Jobs, weil unsere Systeme nach dem erneuten Versuch aufgegeben hatten. Wir arbeiten daran, dieses Verhalten zu ändern. **Wir verbessern unsere Statusseiten-Updates bei langen Vorfällen.** Kunden sagten uns, dass unsere frühen Updates nicht genug Details enthielten. Wir aktualisieren unsere Leitlinien, so dass Updates früher spezifische Auswirkungen und Timing enthalten. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Wir danken unseren Kunden für ihre Geduld, während unser Team daran arbeitete, diesen Vorfall zu lösen. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Oktober 2026 um 09:06 UTCinvestigating

   Kunden können sich beim Start von Docker Gen 2 Jobs verzögern. Wir arbeiten daran, den Durchsatz des Systems zu erhöhen, um diesem gerecht zu werden.

2. 1. Oktober 2026 um 09:47 UTCidentified

   Wir haben die Ursache identifiziert und arbeiten aktiv an einer Lösung. Vielen Dank für Ihre Geduld.

3. 1. Oktober 2026 um 10:13 UTCidentified

   Ein Fix wurde ausgerollt und wir fangen an, die Erholung zu beobachten.

4. 1. Oktober 2026 um 10:24 UTCmonitoring

   Wir sehen, dass die Warteschlangen auf ein normales Niveau zurückkehren und weiterhin überwachen.

5. 1. Oktober 2026 um 10:45 UTCresolved

   Dieser Vorfall wurde behoben.

6. 9. Oktober 2026 um 22:36 UTCpostmortem

   ## **Zusammenfassung** Zwischen dem 1. Oktober und dem 8. Oktober 2026 erlebten CircleCI-Kunden fünf separate Vorfälle, bei denen Jobs länger als normal auf den Start warteten oder nicht starteten. Drei der Vorfälle wurden durch die begrenzte Instanzverfügbarkeit von unserem Cloud-Anbieter verursacht. Eines wurde durch ein Konfigurationsproblem in unserer Planungsinfrastruktur und eines durch Speichergrenzen eines internen Dienstes verursacht, die wir während des Vorfalls angesprochen haben. * **Oktober 1, 07:57 bis 10:24 UTC:** Docker Gen 2 Jobs warteten bis zu 30 Minuten, um zu beginnen. Ein Konfigurationsproblem verhinderte, dass die Gen 2-Planungsserver ihre leistungsstarken lokalen Festplatten verwenden konnten. Während eines Verkehrsstoßes sättigten sich die Fallback-Disks und die Jobplatzierung verlangsamte sich. * **Oktober 7, 13:27 bis 14:06 UTC:** Maschinenjobs warteten länger als normal, weil wir nicht genügend virtuelle Maschinen von unserem Cloud-Anbieter erwerben konnten. * **Oktober 7, 14:24 bis 15:21 UTC:** Einige Jobs scheiterten mit einem Infrastrukturfehler, und Workflows verzögerten sich. Der Dienst, der jedem Auftrag seine Konfiguration beim Start gibt, ist aus dem Speicher und wurde neu gestartet. * **Oktober 7, 18:49 bis 20:05 UTC:** Docker Gen 2-Jobs haben länger als normal gewartet, weil wir nicht genügend Instanzen von unserem Cloud-Anbieter erhalten konnten. * **Oktober 8, 12:48 bis 16:00 UTC:** Linux-Maschinenjobs und Remote-Docker-Jobs warteten bis zu 50 Minuten, um zu starten. Unser Cloud-Anbieter hatte nicht genug von dem von uns angeforderten Instanztyp, und ein Fehler in der Logik, die einen anderen Instanztyp auswählt, hinderte uns daran, Alternativen zu verwenden. Jobs, die während dieser Vorfälle warteten, wurden verzögert, nicht verloren. Kunden, deren Jobs mit einem Infrastrukturfehler während des Vorfalls vom 7. Oktober von 14:24 bis 15:21 UTC gescheitert sind, können sie erneut ausführen. Die ursprünglichen Statusseiten finden Sie unten: * [Oktober 1 - Verzögert den Start von Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g) * [Oktober 7 - Verzögerung beim Starten von Machine Job Tasks](https://status.circleci.com/incidents/tj6wdnfjwr64) * [7. Oktober - Erhöhte Infra-Ausfälle bei Kundenjobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [7. Oktober - Erhöhte Aufgabenwartezeiten für Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [Oktober 8 - Erhöhte Wartezeiten für Maschinenaufträge](https://status.circleci.com/incidents/jn756xtsy4xg) ## **Hintergrund ** Jeder Job, der auf CircleCI läuft, muss berechnet werden. Woher dieser Compute kommt, hängt vom Executor ab. Docker-Jobs laufen auf Clustern von Servern, die die Arbeit für eine Flotte von Instanzen planen. Der Scheduler ist die Software auf diesen Servern, die entscheidet, welche Instanz jeden Job ausführt. Gen 2 Docker Jobs liefen auf einem solchen Cluster zum Zeitpunkt des Vorfalls vom 1. Oktober. Gen 1 Docker Jobs sind auf mehrere Cluster verteilt. Maschinenjobs, einschließlich Remote-Docker-Jobs, erhalten eine dedizierte virtuelle Maschine. Ein Remote-Docker-Job wird als Linux-Maschinenjob von der Einreichung bis zur Bereitstellung bearbeitet. Unser Maschinenbereitstellungsservice fordert jede Maschine von unserem Cloud-Anbieter in einer der beiden Regionen an, die wir normalerweise für Maschinenaufträge verwenden. Wenn der Anbieter den von uns angeforderten Instanztyp nicht bereitstellen kann, greift der Dienst zurück: Er fordert einen anderen Instanztyp oder eine andere Region aus einer von uns verwalteten Liste an. Ein Job wartet, bis eine Maschine verfügbar ist. Wenn ein Job beginnt, fragt er einen Jobkonfigurationsdienst nach seiner Konfiguration. Dieser Dienst läuft als eine Reihe von Pods, die kleine Kopien des gleichen Programms sind. Wenn zu viele Pods aufhören, tragen die verbleibenden Pods mehr Last und Jobs können nicht beginnen, bis sich der Dienst erholt hat. Diese Pfade hängen von drei Arten von Kapazitäten ab: dem Durchsatz unserer Scheduling-Systeme, der Bereitstellung von Instanzen von unserem Cloud-Anbieter und dem Speicher und der Anzahl der Kopien der Dienste, die Jobs starten. Ein Defizit in einem von ihnen lässt Jobs warten oder scheitern. ## **Was geschah ** \(Alle Zeiten UTC\) ### **Oktober 1: Docker Gen 2 Jobs verspätet sich bis zu 30 Minuten ** Um 07:44 Uhr stieg die Festplattenaktivität auf den Servern, die Gen 2 Docker-Jobs planen, auf 90% der Kapazität und blieb dort. Um 07:57 Uhr begann die Zahl der Docker-Jobs, die auf den Start warteten, zu wachsen, und die Wartezeiten stiegen damit. Eine automatisierte Benachrichtigung hat den Bereitschaftstechniker um 08:08 Uhr auf die Seite gebracht. Wir erklärten einen Vorfall um 08:42. Um 08:43 Uhr identifizierten die Ingenieure eine hohe Latenz auf den Planungsservern. Sie glaubten zuerst, dass die Festplatten zu langsam für die Last waren, also bereiteten sie einen Wechsel zu einem schnelleren Festplattentyp vor. Um 09:01 Uhr einigte sich das Team auf zwei Workstreams: Verschieben Sie die Server auf schnellere Festplatten und fügen Sie einen zweiten Gen 2-Cluster hinzu, so dass sich die Jobs auf zwei Cluster aufteilen würden. Um 09:41 Uhr fanden Ingenieure die Ursache. Jeder Planungsserver hat schnelle Festplatten direkt an ihn angeschlossen, und der Scheduler soll seine Arbeitsdaten dort halten. Diese Server laufen auf einem sicherheitsgesicherten Betriebssystemabbild, und auf diesem Bild wurden die schnellen Festplatten nicht verwendet. Der Scheduler schrieb seine Daten stattdessen auf langsamere netzwerkgebundene Festplatten. Das Skript, das die schnellen Festplatten einrichtete, scheiterte ohne Fehler, und eine Lücke in der Protokollierung auf diesen Servern versteckte den Fehler. Auch der Gen 2-Verkehr war immer platzender geworden. Die langsameren Scheiben sättigten sich während dieser Bursts, und der Scheduler fiel zurück. Die Wartezeiten erreichten ihren Höhepunkt um 09:54 Uhr, als Jobs in der mittleren Ressourcenklasse Gen 2 bis zu 30 Minuten warteten. Um 09:55 Uhr wandten die Ingenieure einen Fix an, der die schnellen Festplatten korrekt einrichtete. Um 10:11 Uhr begann der Scheduler, Jobs schneller zu platzieren, was bestätigte, dass die Server mit neuen Jobs Schritt halten konnten. Die Wartezeiten für Gen 2 Medium fielen auf 13 Minuten um 10:14, 7 Minuten um 10:17 und 1 Minute 30 Sekunden um 10:20. Wir haben die Statusseite um 10:24 Uhr auf die Überwachung verschoben und den Vorfall um 10:45 Uhr behoben. Um 11:20 Uhr begann der zweite Gen 2-Cluster, Jobs zu erledigen. ### **Oktober 7, 13:27 bis 14:06: Erhöhte Wartezeiten für Maschinenjobs** Wir erklärten einen Vorfall um 13:27 Uhr, nachdem wir erhöhte Warteschlangen und Wartezeiten gesehen hatten. Wir haben auf der Statusseite um 13:31 gepostet. Um 13:31 Uhr sahen die Ingenieure, dass wir Schwierigkeiten hatten, virtuelle Maschinen für Maschinenjobs zu erwerben, und dass die Anzahl der Jobs, die auf den Start warteten, vor allem für Maschinenjobs hoch war. Um 13:34 Uhr wurden die Wartezeiten zwischen den Executoren erhöht. Um 13:48 Uhr begannen sich die Wartezeiten zu erholen, als mehr Maschinen verfügbar wurden, und wir lösten den Vorfall um 14:06 Uhr. ### **Oktober 7, 14:24 bis 15:21: Jobausfälle und Workflow-Verzögerungen** Kurz nachdem der vorherige Vorfall als behoben markiert wurde, erklärten wir um 14:24 Uhr einen neuen Vorfall aufgrund eines starken Rückgangs der Anzahl der in unseren Ausführungssystemen eingereichten Jobs. Um 14:26 Uhr sahen die Ingenieure, dass Pods des Jobkonfigurationsdienstes neu gestartet wurden. Pods, die neu starten, lassen weniger Kopien des Dienstes zurück, um Anfragen zu beantworten, und Jobs, die ihre Konfiguration nicht abrufen konnten, nachdem wiederholte Versuche mit einem Infrastrukturfehler fehlgeschlagen waren. Workflows, die bereits liefen, warteten auf Updates von Jobs, die noch nicht begonnen hatten. Um 14:35 Uhr erhöhten die Ingenieure die Menge an verfügbarem Speicher für die Pods und erhöhten die Anzahl der Pods, was dem Dienst mehr Kopien gab, um die Last zu teilen. Wir haben auch die Menge an verfügbarem Arbeitsspeicher erhöht, mit deren Wiederherstellung begonnen wurde, und die Anzahl der Nachrichten, die durch unser Workflowsystem fließen, ist auf ein normales Niveau zurückgekehrt. Um 14:44 Uhr haben wir die Statusseite zur Überwachung verschoben. Pods im Job-Konfigurationsdienst erreichten ihre Speichergrenzen und starteten neu. Wir haben die Speicherzuweisungen und Pod-Zahlen erhöht und der Dienst wurde wiederhergestellt. Um 15:13 Uhr haben wir die Anzahl der Instanzen in unseren Gen 2 Docker-Clustern erhöht, so dass wir den Rückstand von Warteaufträgen schnell durcharbeiten konnten. Wir haben den Vorfall um 15:21 Uhr gelöst. ### **Oktober 7, 18:49 bis 20:05: Erhöhte Wartezeiten für Docker Gen 2 Jobs** Wir erklärten einen neuen Vorfall um 18:49 Uhr, nachdem die Wartezeiten von Docker Gen 2 gestiegen waren. Um 18:51 Uhr bestätigten die Ingenieure, dass ein Mangel an verfügbaren Instanzen uns davon abhielt, genug davon zu erwerben, was die Wartezeiten erhöhte. Wartezeiten unterschieden sich durch die Größe der Ressourcenklasse. Um 19:52 Uhr waren die durchschnittlichen Wartezeiten niedriger als eine Stunde früher, da mehr Kapazität verfügbar wurde, obwohl kurze Spitzen anhielten, und wir die Statusseite zur Überwachung verschoben haben. Wir haben den Vorfall um 20:05 Uhr gelöst. ### **Oktober 8: Linux-Maschine und Remote-Docker-Jobs warten bis zu 50 Minuten ** Wir erklärten einen Vorfall um 12:48 Uhr, nachdem wir eine große Anzahl von Jobs gesehen hatten, die auf den Start warteten, und lange Wartezeiten für Maschinen- und Remote-Docker-Jobs. Um 12:49 Uhr sahen die Ingenieure, dass unser Cloud-Anbieter nicht genügend Instanzen liefern konnte. Die Verzögerungen stiegen weiter, als wir untersuchten. Um 13:13 Uhr begannen wir, die Logik zu untersuchen, die einen anderen Instanztyp oder eine andere Region auswählt, wenn unsere erste Wahl nicht verfügbar ist. Um 13:24 Uhr vermuteten wir, dass ein Fehler in dieser Logik uns daran hinderte, andere Instanztypen in unserer primären Region zu verwenden, also deaktivierten wir unsere Fallback-Region und bestätigten die Ursache des Fehlers. Ingenieure begannen mit der Arbeit an einem Fix und setzten ihn um 14:49 Uhr ein. Der Dienst begann, andere Instanztypen anzufordern, und startete Maschinen in großer Zahl. Um 14:58 Uhr sank die Warteschlange der Jobs, die auf eine Maschine warteten, stetig. Die durchschnittlichen Wartezeiten in den Ressourcenklassen gingen in der nächsten Stunde weiter zurück, als wir den Rückstand der Wartejobs durcharbeiteten. Um 16:00 Uhr wurde die Warteschlange für Jobs, die auf eine Maschine warteten, gelöscht und die Anzahl der Wartejobs wurde wieder normal. Wir haben die Statusseite um 16:09 Uhr auf die Überwachung verschoben und den Vorfall um 16:35 Uhr behoben. ## **Zukünftige Prävention und Prozessverbesserung** Wir unternehmen die folgenden Schritte, um die Widerstandsfähigkeit von Arbeitsbeginnzeiten zu stärken, einschließlich Angebotsdiversifizierung, Fallback-Logik und Früherkennung. **Wir erweitern unsere Rechenregionen.** In den Vorfällen vom 7. und 8. Oktober konnte unser Cloud-Anbieter nicht genügend Instanzen in den von uns verwendeten Regionen liefern. Wir fügen unserer Fallback-Logik neue Regionen hinzu, um Nachfragespitzen zu bewältigen, die unsere bevorzugten Regionen übertreffen. ** Wir beheben die Logik, die einen anderen Instanztyp auswählt. ** Am 8. Oktober verhinderte ein Defekt, dass der Maschinenbereitstellungsdienst andere Instanztypen in derselben Region verwendete. Wir haben während des Vorfalls einen Fix bereitgestellt und überprüfen und refactoringen nun diese Logik als Ganzes mit Tests, so dass ein Mangel an einem Instanztyp die Arbeit in einen anderen verschiebt. **Wir erweitern die von uns angebotenen Instanztypen und sichern zusätzliche Kapazitäten.** Wir arbeiten mit unserem Cloud-Anbieter zusammen, um zusätzliche Kapazitäten in unseren bestehenden Regionen zu reservieren, und wir fügen Instanztypen hinzu, auf denen Jobs ausgeführt werden können. Die Nachfrage der Industrie nach Hochleistungsrechnern wächst. Wir diversifizieren, wo und wie wir Kapazitäten beziehen, damit unsere Kunden von Angebotsschwankungen isoliert werden. **Wir haben einen zweiten Gen 2 Docker Cluster hinzugefügt, so dass Traffic Bursts auf zwei Cluster verteilt sind. ** Wir fügen auch Benachrichtigungen zur Planung der Server-Festplattensättigung und dazu hinzu, wie schnell der Scheduler Jobs platziert, und eine Warnung, die ausgelöst wird, wenn ein Server ohne seine schnellen Festplatten startet. Wir haben das Disk-Setup-Skript mit einem Fehler fehlgeschlagen, und wir haben den Protokollversand von diesen Servern wiederhergestellt, so dass ein ähnliches Problem früher sichtbar ist. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Wir danken unseren Kunden für ihre Geduld, während unser Team daran arbeitete, diese Vorfälle zu lösen. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 18:13 UTCidentified

   Kunden können verzögerungen bei neuen anmeldungen und planänderungen erfahren, die sich in ihrem konto widerspiegeln.

2. 23. September 2026 um 20:06 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. September 2026 um 16:22 UTCinvestigating

   Kunden können Verzögerungen beim Starten von Jobs auf Linux Machine auftreten. Wir untersuchen.

2. 21. September 2026 um 16:48 UTCmonitoring

   Die Wartezeiten für Linux Machine werden wieder normal.

3. 21. September 2026 um 17:09 UTCresolved

   This incident has been resolved.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. September 2026 um 14:55 UTCinvestigating

   Wir untersuchen eine Verzögerung bei der Verfügbarkeit von Pipeline-Daten. Pipelines laufen noch, aber Daten über sie können sich in der Benutzeroberfläche oder API verzögern.

2. 16. September 2026 um 15:29 UTCidentified

   Wir haben das Problem erkannt und arbeiten an einer Sanierung. Vielen Dank für Ihre Geduld.

3. 16. September 2026 um 17:34 UTCidentified

   Pipeline-Daten sind jetzt wie gewohnt verfügbar, mit Ausnahme von Testergebnissen, die sich möglicherweise noch verzögern. Wir arbeiten weiter daran, vielen Dank für Ihre Geduld.

4. 16. September 2026 um 18:22 UTCmonitoring

   Alle Pipeline-Daten sind jetzt wie gewohnt verfügbar. Wir werden die Erholung weiterhin überwachen.

5. 16. September 2026 um 19:30 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. September 2026 um 14:42 UTCinvestigating

   Wir sehen derzeit eine Verzögerung beim Auftauchen von Pipeline-Daten in der Benutzeroberfläche.

2. 15. September 2026 um 15:14 UTCidentified

   Wir beginnen eine gewisse Erholung zu sehen.

3. 15. September 2026 um 17:02 UTCresolved

   Der Vorfall, der sich auf Pipeline-Daten in der Benutzeroberfläche auswirkt, wurde nun behoben. Wir danken Ihnen für Ihre Geduld, während unsere Ingenieure daran gearbeitet haben, die Verzögerungen zu reduzieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. September 2026 um 11:59 UTCinvestigating

   Aufgrund erhöhter Netzwerkfehler und Latenzen sehen wir erhöhte Wartezeiten für macOS-Jobs. Wir untersuchen dies mit unserem macOS Hosting Provider.

2. 14. September 2026 um 12:36 UTCinvestigating

   Die Wartezeiten für macOS-Jobs reduzieren sich und wir untersuchen weiter.

3. 14. September 2026 um 12:48 UTCmonitoring

   Unser macOS-Hosting-Anbieter hat eine Minderung implementiert und wir haben verbesserte Latenzen gesehen. Wir werden weiter beobachten.

4. 14. September 2026 um 12:59 UTCresolved

   Die Wartezeiten für macOS-Jobs sind wieder normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. September 2026 um 20:25 UTCidentified

   Eine kleine Anzahl von Kunden sieht möglicherweise Fehler oder kann die Pipeline-Seite für Projekte mit veralteten Konfigurationswarnungen nicht laden, wenn Sie die klassische Pipeline-Ansicht verwenden. Kunden in der Ansicht neue Pipelines sind nicht betroffen. Wir haben die Ursache identifiziert und einen Fix eingesetzt.

2. 10. September 2026 um 20:25 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 10. September 2026 um 20:26 UTCresolved

   Dieser Vorfall wurde behoben. Eine kleine Anzahl von Kunden, die Pipelines zwischen 18:53 UTC und 19:24 UTC erstellt haben, die Config mit veralteter Config-Syntax enthielten, wird gesehen haben, dass ihre Build-Jobs nicht gestartet wurden. Kunden, deren Jobs oder Pipelines fehlgeschlagen sind, können sie erneut ausführen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 4. September 2026 um 15:16 UTCinvestigating

   Wir haben Netzwerkprobleme festgestellt, die sich auf unsere Mac-Infrastruktur auswirken. Wir untersuchen und werden in Kürze Updates bereitstellen. Kunden können während dieser Zeit Schlange stehen.

2. 4. September 2026 um 15:43 UTCidentified

   Wir haben das Netzwerkproblem mit unserem Mac-Infrastrukturanbieter identifiziert und arbeiten mit ihnen zusammen, um das Problem zu lösen. Wir fangen an, eine gewisse Erholung zu sehen, aber wir erwarten, dass die Kunden immer noch Schlange stehen. Wir werden in Kürze wieder aktualisieren.

3. 4. September 2026 um 16:19 UTCmonitoring

   Unser Mac-Infrastrukturanbieter hat dieses Netzwerkproblem behoben und wir sehen, dass die Warteschlangenzeiten wieder normal werden. Wir werden die Dinge noch eine Weile im Auge behalten. Wir werden in Kürze wieder aktualisieren.

4. 4. September 2026 um 16:55 UTCresolved

   Wir haben keine weiteren Auswirkungen auf die Schlangenzeiten gesehen und alles hat sich wieder normalisiert. Wir schätzen Ihre Geduld, während wir daran gearbeitet haben, dieses Problem zu lösen und zu überwachen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. August 2026 um 15:43 UTCidentified

   Kunden können intermittierende Fehler beim Anzeigen von Plannutzungs-Benutzeroberflächen oder beim Aufrufen von Plannutzungs-APIs auftreten. Wir haben das Problem erkannt und arbeiten aktiv daran, diese Fehler zu mildern.

2. 26. August 2026 um 16:04 UTCmonitoring

   Wir haben das Problem mit Plannutzungs-APIs gemildert und die relevanten Seiten in der Benutzeroberfläche werden korrekt geladen.

3. 26. August 2026 um 16:10 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. August 2026 um 23:20 UTCresolved

   Zwischen 19:49 UTC und 21:07 UTC am 25. August 2026 konnten sich Kunden, die sich mit GitHub bei CircleCI anmelden wollten, nicht anmelden und erhielten einen Fehler von GitHub, der angab, dass die Rückruf-URL ungültig war. Kunden, die bereits angemeldet waren, waren nicht betroffen. Das Problem wurde behoben und GitHub Login funktioniert normal. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. August 2026 um 21:06 UTCidentified

   Die Ursache des Problems wurde ermittelt, und wir arbeiten daran, es zu beheben.

2. 17. August 2026 um 21:36 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 17. August 2026 um 21:37 UTCresolved

   Insights-Daten sind wieder einmal gut. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.