Cases2 cases

1 to 2 of 2

1. IL-0327 After a blue/green upgrade of CircleCI's workflows database every query hit disk, and workflow starts lagged or failed

   CircleCI2025

   Symptoms

   On April 3, 2025, from 22:08 to 23:45 UTC, CircleCI customers saw higher latency and some failures when starting and cancelling workflows and jobs, and had delays and trouble viewing workflows in the UI. Nine minutes after the blue/green cutover of the workflows database, the team found increased latency in the workflows service and errors from jobs dropped after using up their 10 minutes of retries.

   High latencyHigh error rateDatabase overload

   Trigger

   A blue/green upgrade of the database behind the CircleCI workflows service cut over to the new database at 22:08 UTC.

   Root cause

   Faulty deployment

   Component

   DatabaseQuery planner and table statistics

   Contributing factor

   –

   Detection

   At 22:17 UTC the team identified increased latency in the workflows service and errors from jobs dropped after exhausting their 10-minute retries.

   Remediation

   • Restarted the workflows pods so all of them connected to the correct database
   • Upsized the new database and disabled non business critical operations on it
   • Scaled the workflows service down to a single pod while the statistics table was rebuilt
   • Re-enabled writes on the old database and restored it as primary

   Action items

   • Run an analysis procedure after every major version change in blue/green database deployments
   • Tested running analyze on a database under pressure, found it does not degrade performance further, and noted this for future remediation
   • Add automated tests and manual checkpoints throughout migrations to catch problems before the blue/green cutover

   View case
2. IL-0294 CircleCI Docker and machine jobs stalled for nearly 12 hours after a VM cleanup queue lost all its RabbitMQ consumers

   CircleCI2021

   Symptoms

   From 13:30 UTC on 21 May 2021, CircleCI jobs on Docker, the Machine executor (including Windows, Mac, Arm and GPU) and remote Docker were delayed or blocked. Engineers had been paged at 13:00 for excessive delays in starting jobs, and the alerts showed CircleCI could not provision some types and classes of VM because it was hitting its CPU quotas in GCP.

   Throughput degradationCloud API rate limit exhaustedDatabase overload

   Trigger

   The upgrade of the RabbitMQ cluster from 3.8.9 to 3.8.16 on 20 May 2021, which brought in a 15 minute consumer acknowledgement timeout for all queue types.

   Root cause

   Breaking change in an upgrade

   Component

   Message brokerDatabase

   Contributing factor

   Change with a delayed effectIgnored early signalRetry stormExcessive blast radiusOverlapping failures

   Detection

   Engineers were paged at 13:00 UTC on 21 May for excessive delays in starting jobs. Earlier, a 02:31 notification that a VM destroyer queue had no consumers was handled by restarting pods, and a 10:11 alert that a VM destroy queue was backing up notified once at its threshold and did not page.

   Remediation

   • Blocked Linux machine jobs from entering the work queue
   • Had GCP raise the CPU quotas
   • Deleted old VMs by hand
   • Cancelled some workflows to free resources
   • Reset the VM services deployment so the VM destroy queues had consumers again
   • Scaled up the RDS database instance, at 18:20 and again at 19:15
   • Turned down VM provisioning and blocked remote-docker jobs to shed load
   • Scaled down all pods that created and destroyed VMs
   • Deployed a revised distribution backend that kept remote-docker jobs out of the provisioning queues
   • Brought provisioning and distribution back one component at a time and reversed the mitigation code changes

   Action items

   • Make VM provisioning more robust to changes in load so it can recover from thundering herds
   • Make VM provisioning independent so its failure does not affect Docker jobs
   • Review and improve observability of RabbitMQ and the production queues
   • Batch requests to avoid hitting GCP API rate limits
   • Improve incident response for long-running incidents

   View case

By root cause2