CircleCI's Docker Jobs component broke on 1 October 2026, delaying Gen 2 Docker job starts for 1h 39m. The fault sat on CircleCI's side, in the system that queues and launches those jobs.
Started
09:06 UTC
Duration
Lasted 1h 39m
Source
IsDown
Next time
CircleCI is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Docker Jobs
What happened?
CircleCI's status page opened an incident at 09:06 UTC titled "Delays starting Gen 2 Docker Jobs", saying customers may see delays starting Docker Gen 2 Jobs while the team worked to increase system throughput. At 09:47 CircleCI said it had identified the root cause and was working on a fix, without naming the cause itself. At 10:13 a fix was rolled out and CircleCI reported it was starting to see recovery. By 10:24 queue times were back to normal levels and the team kept monitoring. The incident was marked resolved at 10:45, giving a total duration of 1h 39m. Only one component was listed as affected throughout: Docker Jobs. No other part of CircleCI's platform appears in the record for this day. There were no user reports filed in this window, so the only account of what happened comes from CircleCI's own five updates. That is a thin record: it tells you what broke and roughly how long it took to fix, but not why the queue backed up in the first place. Over the past 90 days CircleCI has logged 25 incidents with a median duration of 1 hour 42 minutes, so this one lines up almost exactly with its usual pattern rather than standing out as unusual.
Learning
This incident sat in CircleCI's job scheduling layer, the part that queues and starts Docker Gen 2 jobs, not in anything you control or can see from outside. If you were watching your own build pipeline during this window, you would have seen jobs queueing longer than normal with no obvious reason on your end, because the delay originated upstream at CircleCI before your job ever started executing. A simple reachability check against CircleCI's API or dashboard would likely have stayed green the whole time, since the service was up and responding, it was just slow to actually start the jobs you queued. That is the gap between "the provider is reachable" and "the provider is doing what you asked it to do", and it is exactly the kind of fault that doesn't show up as a failed health check. Over CircleCI's last 30 days there have been 8 such incidents with a median duration of 1h 41m, so this is a recurring shape of failure rather than a one-off. Your own monitoring covers your half of the pipeline. UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
