Major incident

CircleCI: Delays starting Docker jobs

Affected: Docker Jobs

Current status of CircleCI: Operational — live CircleCI status

Timeline

1. Jun 23, 2026, 18:34 UTC
   investigating
   We are investigating reports of delays starting Docker jobs.
2. Jun 23, 2026, 18:42 UTC
   identified
   We are deploying a change to mitigate this issue.
3. Jun 23, 2026, 19:04 UTC
   identified
   What's impacted Customers running Docker jobs. Affected jobs are queuing rather than starting, resulting in elevated wait times. What can you expect Docker jobs may remain stuck in "preparing environment" for an extended period. Our engineers have identified the cause and are actively working to restore normal job startup times. Thank you for your patience while our team deploys a fix. Next update We will provide another update as soon as more information is available
4. Jun 23, 2026, 19:29 UTC
   monitoring
   What's happening Our engineers have deployed a fix and we are observing the job backlog clearing. Docker jobs are now starting normally. What's impacted Customers who submitted Docker jobs during the incident window may still see some jobs completing with elevated queue times. Newly submitted jobs should be starting at normal times. What can you expect Docker job startup times are returning to normal. Thank you for your patience while our engineers resolved this issue. We are monitoring the recovery and will provide a further update if the situation changes.
5. Jun 23, 2026, 19:58 UTC
   resolved
   The issue where customers running Docker jobs experienced significant delays, with jobs stuck in a "preparing environment" state, has now been resolved. We thank you for your patience while our team worked on implementing a fix.
6. Jun 27, 2026, 00:15 UTC
   postmortem
   ## Summary On Tuesday, June 23, 2026, our engineering team identified that a single Docker job cluster was operating below expected performance levels. Our infrastructure is organized into routing groups, each responsible for handling a specific segment of traffic, and this cluster was the sole member of its group. To address the performance issue, they initiated a standard two-step procedure to safely take it out of rotation: first, update the routing configuration to stop directing traffic to the cluster, then take it offline. When the team moved to take the cluster offline, the first step of the procedure was skipped. The cluster was removed from the available pool, but the routing configuration was not updated, meaning traffic continued to be directed to the routing group even though it had no capacity to process work. With no other clusters in the routing group to absorb the traffic, affected jobs had nowhere to go and began queuing rather than starting. This is a routine and safe operation when the two-step procedure is followed correctly, this incident exposed a gap in our tooling that allowed the procedure to be completed out of order. The issue began at approximately 17:25 UTC and was fully resolved by 19:46 UTC, for a total impact window of roughly 2 hours and 20 minutes. Only Docker jobs were affected; other job types, including machine and macOS jobs, continued to operate normally. Beyond the missed step, several factors extended the impact window. An automated alert fired within a minute of the change deploying, but was dismissed as expected behavior. This delayed detection by nearly an hour. When engineers attempted to accelerate recovery by restoring a prior known-good version, they encountered unexpected issues with the rollback process, adding further delay before the fix could be deployed. The original status page for this incident can be found [here](https://status.circleci.com/incidents/rp9y8kszn25j). ## How Job Routing Works CircleCI uses Nomad as its job scheduling system for Docker-based jobs. When a job is triggered, it is routed to one of several Nomad clusters, organized into routing groups each responsible for handling a specific segment of traffic. This multi-cluster architecture is intentional: clusters are isolated from one another so that an issue in one does not impact the others, limiting blast radius and improving overall resiliency. Under normal circumstances, if a cluster becomes unavailable, traffic is automatically rerouted to the remaining operational clusters in its routing group, allowing jobs to continue without interruption. ## What Happened \(All times UTC\) Prior to the incident, our engineering team identified that a single Docker job cluster was operating below expected performance levels. Our infrastructure is organized into routing groups, each responsible for handling a specific segment of traffic, and this cluster was the sole member of its group. To address the performance issue, they initiated a standard two-step procedure to safely take it out of rotation. At 16:58, our engineering team applied a configuration change to remove the affected cluster from service. The first step of the two-step procedure was missed. The cluster was removed from the available pool, but the routing configuration was not updated, leaving traffic still being directed to a routing group with no capacity to process it. When the configuration change was fully deployed at 17:25, the affected jobs began to queue. At 17:26, our monitoring alerted us to reduced job throughput on the affected cluster. Because throughput on that cluster was expected to drop as part of the cluster rotation procedure, the alert was interpreted as expected behavior and no action was taken. By 18:19, a series of customer support tickets made clear that something beyond expected behavior was occurring. A formal incident was declared at 18:28 and engineers began investigating. By 18:33, the team confirmed the impa

Updates as published by CircleCI (original).