{"id":"IL-0553","org":"CircleCI","date":"2026-10-06","docs":[],"title":{"en":"CircleCI's orchestration database filled its transaction log volume, and no workflows or jobs started for 50 minutes","ko":"워크플로 조율 서비스의 데이터베이스에서 트랜잭션 로그 볼륨이 차서 CircleCI 파이프라인과 잡이 멈추고 몇 시간 동안 늦게 시작했다"},"domain":["database"],"impact":{"scope":"Creating pipelines and starting workflows and jobs on CircleCI was delayed from 15:30 to 20:30 UTC and stopped from 15:48 to 16:38 UTC; pipelines triggered from 16:02 UTC failed; UI data, notifications and commit status updates were delayed; about 3,500 jobs failed to start","users":"CircleCI customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"CircleCI says the combination of alerts should have been recognised sooner: brief error alerts that cleared on their own were treated as routine, and nothing alerted on the transaction log volume or on archiving lag. Because every write of the orchestration service went through one database and one transaction log, a backlog in that log slowed every pipeline, workflow and job.","ko":"CircleCI 는 여러 알림이 함께 울린 것을 더 일찍 알아챘어야 했다고 밝혔다. 모니터링은 느려진 것을 잡았지만 트랜잭션 로그 볼륨이 찬 정도와 보관 처리가 밀린 정도에는 알림이 없었다. 조율 서비스의 모든 쓰기가 데이터베이스 하나와 트랜잭션 로그 하나를 거치기 때문에, 그 로그가 밀리자 모든 파이프라인, 워크플로, 잡이 함께 느려졌다. 일부 잡은 다른 시스템들이 재시도 끝에 포기해서 실패했다. 고객들은 초기 상태 페이지 공지에 세부 내용이 부족했다고 알려 왔다."},"related":[],"sources":[{"url":"https://status.circleci.com/incidents/z4hbq8h49j8c","kind":"official-status","archived":"https://web.archive.org/web/20261006200134/https://status.circleci.com/incidents/z4hbq8h49j8c"}],"summary":{"en":"CircleCI's workflow orchestration service tracks the state of every pipeline, workflow and job, decides when each job is ready, hands ready jobs to the execution fleet, and drives the job data in the UI, notifications and commit statuses. The service keeps its state in one database. The database writes every change to a transaction log on a dedicated storage volume and archives the logs continuously so the space can be reused; if archiving falls behind and the volume fills, the database stops accepting writes. On a very large table, the periodic autovacuum maintenance reads every page and writes a large volume of transaction logs.\n\nOn 6 October 2026, from around 12:40 UTC, anti-wraparound autovacuum on several of the largest tables wrote transaction logs faster than they could be archived, and the log volume began to fill. The orchestration service slowed from 13:30, short error alerts that had appeared since 10:02 were handled as routine, and the incident was declared at 14:54. Engineers tuned the autovacuum settings so it would finish faster. At 15:43 the log volume was close to full, and to keep the database from going read-only engineers moved the transaction logs to the database's main storage volume, which had plenty of free space. The move took the database offline from 15:47 for a time nobody could predict; from 15:48 to 16:38 the service processed no work, and pipelines triggered from 16:02 failed. A replacement database was prepared as a fallback, but the original came back first and stayed in service.\n\nWith logs and data on the same storage, the database ran at about half its normal rate from 16:38 to 18:19, and it had to finish archiving its log backlog before the logs could return to a dedicated volume. Engineers changed database parameters to stop more maintenance runs from starting, prepared ways to cut the work reaching the service, and prepared a complete second stack of the service that they could move to at the risk of data loss; CircleCI opted against that move. At 18:19 a database setting change cut the time each write waited on storage, processing speed recovered, and added database and server capacity for the systems that hand jobs to the execution fleet helped clear the backlog. New jobs started on time again by about 19:55, Docker jobs on larger resource classes then waited while capacity scaled up, and start times were normal by 20:30. The incident was resolved at 21:19 UTC. About 3,500 jobs failed to start, some because CircleCI's systems gave up after retrying, and CircleCI found no evidence that any job ran more than once.","ko":"CircleCI 의 워크플로 조율 서비스는 모든 파이프라인, 워크플로, 잡의 상태를 추적하고 준비된 잡을 실행 플릿에 넘긴다. UI 에 보이는 잡 데이터와 작업이 끝났을 때 보내는 알림과 커밋 상태도 이 서비스가 만든다. 이 서비스의 상태를 담는 데이터베이스는 모든 변경을 전용 저장 볼륨의 트랜잭션 로그에 먼저 쓰고 그 로그를 계속 보관 처리해 공간을 다시 쓴다. 보관 처리가 밀려 볼륨이 차면 데이터베이스는 쓰기를 받지 않는다. 데이터베이스는 테이블마다 내부 기록을 유효하게 유지하는 autovacuum 유지 보수 작업을 주기적으로 돌리는데, 아주 큰 테이블에서는 이 작업이 테이블의 모든 페이지를 읽고 트랜잭션 로그를 대량으로 쓴다.\n\n2026년 10월 6일 12시 40분쯤 가장 큰 테이블 몇 개의 autovacuum 이 트랜잭션 로그를 보관 처리 속도보다 빠르게 쓰기 시작했고 로그 볼륨이 차오르기 시작했다. 엔지니어들은 10시 2분부터 울리던 짧은 오류 알림을 전에도 본 비슷한 알림으로 보고 런북대로 대응했다. 13시 30분부터 조율 서비스가 느려지고 여러 서비스의 알림이 함께 울렸으며, 14시 54분에 장애를 선언했다. 엔지니어들은 느려진 원인이 anti-wraparound autovacuum 이라는 것을 찾아냈다. 이 작업은 취소하면 데이터베이스가 자동으로 다시 시작하기 때문에, 엔지니어들은 작업이 빨리 끝나도록 설정을 바꿨다.\n\n15시 43분에 트랜잭션 로그 볼륨이 거의 찼다. 데이터베이스가 읽기 전용이 되는 것을 막으려고 엔지니어들은 로그를 여유 공간이 많은 데이터베이스의 주 저장 볼륨으로 옮기기로 했다. 옮기는 동안 데이터베이스가 내려가야 했고, 15시 48분부터 16시 38분까지 50분 동안 조율 서비스가 아무 작업도 처리하지 못했다. 엔지니어들은 그동안 대체 데이터베이스를 준비했지만 원래 데이터베이스가 먼저 돌아와 그대로 썼다. 로그와 일반 데이터가 같은 저장소를 쓰게 되자 데이터베이스는 평소의 절반쯤 되는 속도로 작업을 처리했다. 엔지니어들은 유지 보수 작업이 더 시작되지 않도록 데이터베이스 파라미터를 바꿨고, 데이터 손실 위험을 안고 옮겨 갈 수 있는 서비스 전체 스택도 준비했지만 옮기지 않기로 했다.\n\n18시 19분에 엔지니어들이 쓰기마다 저장소를 기다리는 시간을 줄이는 데이터베이스 설정을 바꾸자 처리 속도가 돌아왔다. 잡을 실행 플릿에 넘기는 시스템에 데이터베이스와 서버 용량을 더해 밀린 작업을 빨리 처리했고, 19시 55분쯤 새 잡이 제때 시작했다. 밀린 작업이 실행 플릿에 몰려 일부 Docker 잡이 용량이 늘 때까지 기다렸고, 20시 30분에 잡 시작 시간이 정상으로 돌아왔다. 20시 32분에 상태 페이지 공지를 모니터링 단계로 바꾸고 21시 19분에 장애를 종료했다. 잡 3,500개쯤이 시작하지 못했고, CircleCI 는 어떤 잡도 두 번 실행한 증거를 찾지 못했다."},"trigger":{"en":"Around 12:40 UTC, on top of the regular workload, anti-wraparound autovacuum runs on several of the largest tables of the orchestration service's database began writing transaction logs faster than the database could archive them.","ko":"10월 6일 12시 40분쯤 데이터베이스의 가장 큰 테이블 몇 개에서 돌던 정기 유지 보수 작업인 anti-wraparound autovacuum 이 평소 작업량과 겹치면서, 데이터베이스가 트랜잭션 로그를 보관 처리하는 속도보다 빠르게 로그를 썼다."},"severity":"unknown","symptoms":["high-latency","service-unavailable","throughput-degraded","node-disk-full"],"timeline":{"detected_after":"5m","resolved_after":"7h"},"date_kind":"incident","detection":{"en":"Monitoring raised short alerts about errors in the orchestration service from 10:02 UTC, each clearing on its own. At 13:35 the alerts came back together with related alerts from several other services, and after they returned around 14:30 and engineers investigated further, an incident was declared at 14:54 UTC.","ko":"10시 2분부터 모니터링이 조율 서비스의 오류 알림을 짧게 여러 번 냈지만 매번 저절로 풀렸다. 13시 35분에 여러 다른 서비스의 관련 알림과 함께 다시 울렸고, 14시 30분쯤 알림이 다시 울리자 더 조사한 뒤 14시 54분에 장애를 선언했다. 트랜잭션 로그 볼륨이 얼마나 찼는지와 보관 처리가 얼마나 밀렸는지를 보는 알림은 없었다. 상태 페이지에는 15시 58분에 공지를 올렸고 16시 20분에 주요 장애로 올렸다."},"components":["database","autovacuum","ci-system"],"root_cause":"capacity","remediation":[{"text":{"en":"Changed the anti-wraparound autovacuum settings to help it finish faster","ko":"anti-wraparound autovacuum 이 빨리 끝나도록 설정을 바꿨다. 이 작업은 취소하면 데이터베이스가 자동으로 다시 시작하기 때문이었다."}},{"text":{"en":"Moved the transaction logs onto the database's main storage volume, which took the database offline from 15:47 to 16:38 UTC","ko":"트랜잭션 로그 볼륨이 거의 차자 데이터베이스가 읽기 전용이 되지 않도록 로그를 여유 공간이 많은 데이터베이스의 주 저장 볼륨으로 옮겼다. 옮기는 동안 데이터베이스가 50분 동안 내려갔다."}},{"text":{"en":"Changed database parameters to stop further maintenance runs from starting","ko":"유지 보수 작업이 더 시작되지 않도록 데이터베이스 파라미터 몇 가지를 조사해 바꿨다."}},{"text":{"en":"Changed a database setting at 18:19 UTC to cut the time each write spent waiting on storage","ko":"18시 19분에 쓰기마다 저장소를 기다리는 시간을 줄이는 데이터베이스 설정을 바꿔 처리 속도를 되살렸다."}},{"text":{"en":"Added database and server capacity to the systems that hand jobs to the execution fleet to clear the backlog faster","ko":"밀린 작업을 빨리 처리하려고 잡을 실행 플릿에 넘기는 시스템에 데이터베이스와 서버 용량을 더했다."}}],"action_items":[{"text":{"en":"Alert on how full the transaction log volume is and on how far archiving has fallen behind","ko":"트랜잭션 로그 볼륨이 얼마나 찼는지와 보관 처리가 얼마나 밀렸는지에 알림을 건다."}},{"text":{"en":"Alert on the database maintenance that drives transaction log growth","ko":"이 두 상태를 일으키는 데이터베이스 유지 보수 작업에도 알림을 걸어 더 일찍 대응한다."}},{"text":{"en":"Review all alerts so that noisy or sensitive alerts do not hide real issues","ko":"시끄럽거나 지나치게 민감한 알림이 실제 문제를 가리지 않도록 모든 알림을 다시 살핀다."}},{"text":{"en":"Tune how often and how aggressively autovacuum runs on the database","ko":"데이터베이스의 autovacuum 이 얼마나 자주, 얼마나 공격적으로 도는지를 조정한다."}},{"text":{"en":"Track the size of the largest tables over time so they stay within safe limits","ko":"큰 테이블들의 크기를 시간에 따라 추적해 안전한 한계 안에 두게 한다."}},{"text":{"en":"Remove the single transaction log bottleneck by splitting the service across several database instances or moving it to a distributed database","ko":"트랜잭션 로그 하나에 모든 쓰기가 몰리는 병목을 없앤다. 서비스를 각자 트랜잭션 로그를 가진 여러 데이터베이스 인스턴스로 나누는 방법과, 쓰기를 여러 노드에 나누는 분산 데이터베이스로 옮기는 방법을 검토한다."}},{"text":{"en":"Make CircleCI's systems wait for the orchestration service to recover instead of failing jobs after retrying","ko":"다른 시스템들이 재시도 끝에 포기하지 않고 조율 서비스가 회복할 때까지 기다리도록 동작을 바꾼다."}},{"text":{"en":"Include specific impact and timing sooner in status page updates during long incidents","ko":"긴 장애 동안 상태 페이지 공지가 구체적인 영향과 시각을 더 일찍 담도록 지침을 고친다."}}],"contributing":["early-signal-ignored","no-alert-on-limit","single-point-of-failure"],"recurrence_of":null,"symptoms_text":{"en":"On 6 October 2026 CircleCI pipelines were slow to be created and workflows and jobs were slow to start, in short bursts from 13:30 UTC and continuously from 15:30 UTC. From 15:48 to 16:38 UTC no workflows or jobs started at all, and pipelines triggered from 16:02 UTC failed.\n\nFrom 10:02 UTC, monitoring raised short-lived alerts about errors in the workflow orchestration service, and each cleared on its own within about 15 minutes. Engineers had seen similar brief alerts before and the system showed no other signs of stress, so each time the engineers followed the runbook and also began work to make the alerts less sensitive. At 13:35 the alerts returned together with related alerts from several other services, and again around 14:30, and an incident was declared at 14:54. No alert existed on how full the transaction log volume was or on how far log archiving had fallen behind.\n\nOnce the slowdown was traced to an anti-wraparound autovacuum, cancelling it was no answer, because the database restarts that process automatically when it is cancelled. Engineers changed its settings to help it finish faster, but by 15:30 the delays were continuous and some jobs began to fail.\n\nUI data, notifications and commit status updates to version control providers were delayed as well; early status updates said job, workflow and pipeline data could take up to 15 minutes to appear in the UI and outbound notifications and webhooks were up to 1 minute late. After the database came back at 16:38 it processed work at about half its normal rate until 18:19, and jobs waited tens of minutes to start, up to about 50 minutes at the longest. When the backlog reached the execution fleet, some Docker jobs on larger resource classes waited up to about 10 minutes from 19:49 to 20:30 while capacity scaled up; the status page put the peak at around 20:05 UTC, with waits of up to about 8 minutes for 2xlarge gen2 and 6 minutes for xlarge gen2. About 3,500 jobs failed to start.","ko":"2026년 10월 6일 13시 30분 UTC부터 CircleCI 의 워크플로 조율 서비스가 느려져 일부 파이프라인과 잡이 이따금 조금씩 늦게 시작했다. 15시 30분부터는 지연이 계속 이어졌고 일부 잡이 실패하기 시작했다.\n\n그 전인 10시 2분부터 모니터링이 조율 서비스의 오류 알림을 짧게 여러 번 냈다. 알림은 매번 15분쯤 안에 저절로 풀렸다. 엔지니어들은 비슷한 짧은 알림을 전에도 봤고 다른 이상 신호도 없어서 매번 런북대로 대응했다. 알림을 덜 민감하게 만드는 작업도 시작했다.\n\n13시 35분에 모니터링이 다시 알림을 냈고, 이번에는 여러 다른 서비스의 관련 알림이 함께 울렸다. 인프라 엔지니어들이 런북대로 일부 알림을 정리했지만 14시 30분쯤 알림이 다시 울렸고, 더 조사한 뒤 14시 54분에 장애를 선언했다.\n\n15시 48분부터 16시 38분까지 조율 서비스는 어떤 작업도 처리하지 못했다. 고객은 파이프라인을 트리거할 수는 있었지만 워크플로와 잡은 하나도 시작되지 않았고, 16시 2분부터 새로 트리거한 파이프라인은 실패했다.\n\n데이터베이스가 돌아온 16시 38분부터 18시 19분까지 조율 서비스는 평소의 절반쯤 되는 속도로 작업을 처리했다. 잡은 시작까지 수십 분을 기다렸고 가장 길게는 50분쯤 기다렸다. 상태 페이지는 시작 시간이 한때 평균 40분쯤까지 늘었고 아주 적은 수의 워크플로는 1시간 넘게 기다렸다고 적었다.\n\nCircleCI UI 에 잡, 워크플로, 파이프라인 데이터가 나타나기까지 최대 15분이 걸렸다. 외부로 나가는 알림과 웹훅, 버전 관리 서비스로 보내는 커밋 상태 갱신도 늦어졌다. 알림과 웹훅은 19시쯤까지 보통 1분쯤 늦게 나갔다.\n\n밀린 작업이 실행 플릿으로 넘어가자 19시 49분부터 20시 30분까지 큰 리소스 클래스의 Docker 잡이 용량이 늘어나는 동안 최대 10분쯤 기다렸다. 상태 페이지는 20시 5분쯤 대기 시간이 2xlarge gen2 에서 최대 8분쯤, xlarge gen2 에서 6분쯤, 다른 몇몇 리소스 클래스에서 5분 미만이었다고 적었다."},"updated_at":"2026-11-14T12:34:20.344182Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0553","org_slug":"circleci"}