Cases4 cases

1 to 4 of 4

1. IL-0552 CircleCI's archival database ran out of storage, slowing workflow and job starts and the display of workflows in the UI

   CircleCI2025

   Symptoms

   At about 23:00 UTC on 21 January 2025, an automated alert reported that the CircleCI database instance holding archived data was almost out of free storage space. From 23:50 UTC customers saw slow starts and cancellations of workflows and jobs, and delays and difficulty viewing workflows in the CircleCI UI, although pipelines for a specific project could still be viewed.

   High latencyIntermittent timeoutsLog floodNode disk fullCloud API rate limit exhausted

   Trigger

   A code change to a function in the archival database on 16 January 2025 unintentionally made it write an excessive number of log messages, and the database filled its storage.

   Root cause

   Faulty deployment

   Component

   DatabaseCI system

   Contributing factor

   Change with a delayed effectExcessive blast radiusOverlapping failures

   Detection

   An automated alert at about 23:00 UTC warned that the archival database was almost out of free storage, before customers were affected. The growing workflows queue was not linked to it at first because a separate alert about request volume fired at about the same time.

   Remediation

   • Scaled up the event consumer that processes the workflows queue at 23:44 UTC
   • Promoted a read replica of the archival database to a standalone primary at 23:55 UTC

   Action items

   • Fix the database function so it no longer writes an excessive number of log messages
   • Add a max duration to the workflows retry policy for archiving so it fails earlier than the default timeout
   • Move workflow archival to an event-based model that decouples it from the workflows service
   • Add forecast and anomaly monitoring for databases that alerts on unusual activity before it reaches critical levels

   Lessons

   The storage alert on the archival database did fire, but the database filled much faster than forecast, so there was little time to act before customers were affected. Because the workflows service called the archival service synchronously, a problem in the archival database slowed the whole workflows service.

   View case
2. IL-0328 A field type change in the database of CircleCI's job distribution service left all jobs stuck in "not running"

   CircleCI2021

   Symptoms

   From about 18:50 to 19:43 UTC on Monday, November 8, 2021, CircleCI customer jobs on all executors were blocked in a "not running" state. Errors and alerts appeared right after a deploy that changed a field type in the database of the job distribution service.

   Service outageHigh latencyScale-up failureCloud API rate limit exhausted

   Trigger

   At 18:50 UTC a deploy changed the type of a field in the PostgreSQL database of the job distribution service, in a way that was not backwards compatible.

   Root cause

   Faulty deployment

   Component

   DatabaseNode pool

   Contributing factor

   Ineffective rollbackExcessive blast radiusGap in automated tests

   Detection

   Errors and alerts related to the distribution failure appeared immediately after the 18:50 UTC deploy.

   Remediation

   • Rolled back the field type change, which did not clear the errors
   • Wrote, built and manually deployed a change that made the distribution system ignore the field
   • Manually scaled the primary compute cluster for the expected thundering herd of work
   • Monitored until processing was normal and resolved the incident

   Action items

   • Fix the gaps found in the testing strategy
   • Change how the distributor reacts to unexpected data so that this kind of deploy should not affect all jobs
   • Make recovery faster when unforeseen failures occur

   View case
3. 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
4. IL-0333 A downsized RDS PostgreSQL database maxed out its CPU at US peak and failing ELB health checks took buildkite.com down

   Buildkite2016

   Symptoms

   On 22 August 2016 at 17:21 UTC buildkite.com went offline: nobody could log in, view build logs or read the documentation, although builds kept running and GitHub and Bitbucket pull request statuses kept updating. The Buildkite team in Melbourne was asleep and woke at 21:00 UTC, almost 4 hours later, to emails, tweets and Slack messages saying Buildkite was down.

   Service outageDatabase overloadProbe failuresCloud API rate limit exhausted

   Trigger

   Over a weekend maintenance window, Buildkite downgraded its m4.10xlarge Multi-AZ RDS PostgreSQL database to an r3.2xlarge Multi-AZ instance to cut its AWS bill, and moved to a centralised pgbouncer to pool connections. The first US weekday peak after the change pushed the new instance's CPU to its maximum at about 16:00 UTC.

   Root cause

   Capacity exhaustion

   Component

   DatabaseCloud load balancerLiveness and readiness probesNode launch template

   Contributing factor

   Unverified assumptionHealth check tied to a dependencyAutomation amplificationCircular dependencyPages not deliveredOverlapping failures

   Detection

   New Relic, Pingdom, Datadog, Calibre and CloudWatch raised PagerDuty alerts, but the on-call phone call never came and only silent push notifications arrived. The team noticed at 21:00 UTC when they woke to emails, tweets and Slack messages from users.

   Remediation

   • Moved servers from the Agent API to the dashboard ELB to bring buildkite.com back online
   • Switched the Auto Scaling Groups to EC2 health checks and locked in desired counts
   • Upgraded the database to an instance type that could handle the load, using the aws-cli
   • Built a new AMI that did not depend on buildkite.com/_secret/version and rolled out servers that could self-deploy
   • Removed the centralised pgbouncer and went back to pgbouncer on each host

   Action items

   • Plan load testing after significant infrastructure changes without affecting other users of the system
   • Make the ELB health check return OK when the app answers, without checking database connectivity
   • Consider a separate health check endpoint for Pingdom that checks the database and other dependencies
   • Store the latest deployed revision as a file on S3 for newly launched servers to self-deploy from
   • Test by hand that PagerDuty calls reach every on-call team member
   • Investigate regular company-wide tests of everyone's paging setup
   • Ask PagerDuty about calling members when they go on call or requiring an immediate phone rule

   Lessons

   Buildkite listed six lessons. Watch AWS credits, because billing reports show $0 while credits are spent, so the real cost is hidden and big changes end up rushed. Load test after significant infrastructure changes. Think about what a health check should do and what happens when every server behind an ELB fails it. Do not make new servers look up the deployed revision from the service they are replacing. Make sure every on-call member has the right PagerDuty and phone settings before going on call. When servers churn in AWS, stop health checks and autoscaling, for example with the Auto Scaling feature to suspend and resume processes, so the EC2 request limit is not used up.

   View case

By root cause3