CircleCI Status

Investigating: We are still investigating reports that some customers cannot access their organizations in CircleCI.

Early findings suggest the problem may be related to GitHub authorization, where affected users receive a 403 from GitHub indicating the resource is SAML protected and the OAuth token may not be authorized.

We have not yet confirmed this as the root cause. As a potential workaround, some users may be able to restore access by performing a re-authentication: https://support.circleci.com/hc/en-us/articles/360051228052-How-to-Perform-a-Re-Authentication

We will post another update once we have more certainty.

Investigating: We are continuing to investigate reports that some customers are unable to access their organizations in CircleCI. Those affected may see errors when loading their organizations.

Our engineering team are still working to identify the cause. We will share another update as soon as we have more information.

Investigating: We are investigating reports that some customers are unable to access their organizations in CircleCI. Those affected may see errors when loading their organizations.

Our engineering team is actively investigating.

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.

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 impact was isolated to a subset of Docker jobs and identified a large backlog of queued jobs. At 18:41, a fix was merged to restore the affected cluster back into the available pool. Deployment of that fix was delayed because the CI smoke tests assume functioning clusters, leading to some rework of the pipeline itself. In parallel, the team attempted to accelerate recovery at 18:54 by restoring a prior known-good configuration directly, but encountered a conflict that left multiple active versions running simultaneously, preventing a clean rollback. The fix was fully deployed at 19:20 and Docker jobs began processing again.

By 19:28, the team confirmed the backlog was actively clearing and newly submitted jobs were starting at normal times.

Customers who had accumulated queued jobs during the incident period may have experienced a surge in concurrent job starts upon recovery, potentially hitting plan concurrency limits, which would have resulted in jobs still queueing while we processed the backlog.

In total, the period during which Docker jobs were unable to start lasted from approximately 17:25 to 19:20, roughly 1 hour and 55 minutes. The additional time from 19:20 to 19:46 was spent processing the accumulated backlog, during which some previously queued jobs completed with elevated wait times.

Future Prevention and Process Improvement

We are taking the following steps to prevent a recurrence and improve our response time:

We are strengthening our failover architecture. Our multi-cluster design is built for resiliency, and while automatic failover mechanisms are already in place, this incident exposed a gap in our safeguards. We are closing that gap to ensure traffic is rerouted to healthy clusters across routing groups regardless of whether a cluster goes down unexpectedly or is intentionally taken offline.

We are enhancing our cluster rotation procedure. This incident was possible because our tooling allowed an invalid state to exist, a cluster removed from the available pool while the routing configuration still directed traffic to it. We are updating this tooling to enforce that routing configuration and cluster availability are always updated together, and that the procedure cannot be completed out of order.

We are improving our monitoring and alerting. The automated alert that fired during this incident was dismissed because it appeared consistent with the operation being performed. We are improving our monitoring so that unexpected side effects are surfaced clearly and are not confused with expected behavior.

We are improving our rollback capabilities. During the incident, our team encountered delays when attempting to deploy the fix. We are auditing our deployment configurations to ensure that rollbacks can be executed more quickly and reliably during incidents.

Reliability is our top priority, and we are committed to ensuring that infrastructure upgrades like this one are executed with the appropriate safeguards in place.

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.

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.

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

Identified: We are deploying a change to mitigate this issue.

Investigating: We are investigating reports of delays starting Docker jobs.

Resolved: We are concluding this incident based on a confirmed fix with our infrastructure provider and successful tests. For any customers seeing failed runs, please run again for a successful connection.

Monitoring: A fix has been implemented and we are monitoring the results.

Investigating: Due to continued reports of intermittent failures and a lack of sustained improvement while in monitoring status, this incident is elevated back to investigating to escalate with our infrastructure provider.

Monitoring: We are continuing to monitor. We still observe a low percentage of intermittent failures. The failure rate is trending down as we continue to monitor. We advise customers to contact CircleCI Support if they see a change in degraded services and increased failure rate.

Monitoring: We are continuing to monitor for any further issues.

Monitoring: Our team is moving this incident to Monitoring status based on significant improvement seen in our tests and low error rate. We are seeing improvement in network routing for Mac jobs and are actively engaged with our infrastructure provider. If your Mac jobs experience network-related failures or degraded service please reach out to CircleCI support.

Identified: We are seeing improvement in Mac job network routing.

We will continue to monitor for signs of recovery.

Identified: Mac jobs are still seeing intermittent failures with network routing.

We are working with our infrastructure provider to address the networking issues.

Identified: We have implemented a change to address the routing issues and are monitoring the results.

Investigating: What's happening Our engineers are investigating network routing issues for some Mac jobs.

What's impacted Mac jobs that make outbound requests, including checking out from GitHub.