{"id":"IL-0470","org":"Buildkite","date":"2026-05-28","docs":[],"title":{"en":"Buildkite notifications were delayed after Prometheus storage filled and EKS notification workers could not autoscale","ko":"알림 처리 워커가 모자라 Buildkite 알림 전달이 두 차례 늦어졌다"},"domain":["kubernetes","aws","observability"],"impact":{"scope":"Delayed Buildkite notifications (GitHub commit status, email, Slack and webhook) from 20:01 to about 21:00 UTC, and again from 22:12 to 22:40 UTC for a subset of customers; downstream CI, merge and deployment workflows that depend on the notifications were delayed","users":"A subset of Buildkite customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Buildkite said recovery took longer than expected because the rollback path from EKS to ECS did not fully handle this failure, and that its public status page did not show the customer-visible impact as quickly or clearly as it should have, since notification latency affects customers differently depending on how their CI and deployment workflows use notifications.","ko":"Buildkite 는 롤백 경로가 이번 상황을 다 다루지 못해 복구가 예상보다 오래 걸렸다고 보았다. 알림 지연의 영향은 고객이 알림을 CI 와 배포 흐름에 어떻게 쓰는지에 따라 다르게 나타난다. Buildkite 는 공개 상태 페이지가 고객이 겪는 영향을 제때 분명하게 보여 주지 못했다고 밝혔다."},"related":[],"sources":[{"url":"https://www.buildkitestatus.com/incidents/8zy2b81jz4r9","kind":"official-status","archived":"https://web.archive.org/web/20260613160048/https://www.buildkitestatus.com/incidents/8zy2b81jz4r9"}],"summary":{"en":"Buildkite was moving its notification-processing workloads from its earlier ECS-based infrastructure to EKS. On 28 May 2026 the Prometheus service used by the EKS autoscaling path ran out of storage, so some EKS-based workers could not autoscale correctly while queues grew. From 20:01 UTC the notification-processing workers were underprovisioned and notification delivery latency rose. Internal queue latency monitoring caught it and engineers began moving the affected workloads from EKS back to ECS. The rollback took longer than expected because the ECS services were not ready to take the full load at once, and engineers had to adjust scaling configuration and worker counts by hand during the incident. Latency recovered for most customers by 21:00 UTC.\n\nSome workloads were still running on EKS and had started autoscaling again after Prometheus recovered, but the team believed they were no longer serving traffic. When the infrastructure configuration was reconciled, those EKS workloads were scaled down before their ECS equivalents had fully scaled up, and from 22:12 to 22:40 UTC some notification-processing workers were underprovisioned again for a subset of customers. Completing the rollback and scaling the remaining affected ECS services ended it. Buildkite also increased Prometheus storage, added an alert ahead of storage exhaustion, and fixed GitHub notification retry behaviour for a class of errors that could cause repeated retries and lengthen notification delays. The public status page posted its first investigating notice at 20:20 UTC and marked the incident resolved at 21:18 UTC.","ko":"2026-05-28 에 Buildkite 의 알림 처리 인프라 일부가 용량이 모자라 알림 전달 지연이 늘었다. EKS 의 오토스케일링이 쓰는 Prometheus 의 저장 공간이 다 차서 큐가 쌓이는 동안 EKS 위의 워커 일부가 제대로 늘지 못했기 때문이다. 20:01 UTC 에 지연이 시작됐다. 팀은 내부 큐 지연 모니터링으로 이를 알아채고, 영향받은 워크로드를 EKS 에서 이전 인프라인 ECS 로 되돌리기 시작했다. 되돌아갈 ECS 서비스가 전체 부하를 바로 받을 준비가 되어 있지 않아서 엔지니어가 장애 중에 스케일링 설정과 워커 수를 손으로 조정했다. 대부분 고객의 지연은 21:00 UTC 에 풀렸다.\n\n첫 회복 뒤에도 일부 워크로드는 EKS 에 남아 있었고, Prometheus 가 회복하자 다시 오토스케일링하고 있었다. 팀은 이 워크로드가 더는 트래픽을 받지 않는다고 잘못 판단했다. 인프라 설정을 다시 맞추는 동안, 짝이 되는 ECS 서비스가 다 늘어나기 전에 이 EKS 워크로드가 먼저 줄어들었다. 그래서 22:12 부터 22:40 UTC 까지 일부 고객에게 두 번째 지연이 생겼다. 팀은 롤백을 마저 끝내고 남은 ECS 서비스를 늘려 이 지연을 해소했다. 롤백 경로가 이런 상황을 다 다루지 못해 복구가 예상보다 오래 걸렸다."},"trigger":{"en":"The Prometheus service used by Buildkite's EKS autoscaling path ran out of storage, so some EKS-based notification workers could not autoscale while their queues were growing.","ko":"EKS 의 오토스케일링이 쓰는 Prometheus 서비스의 저장 공간이 다 찼다. 그래서 큐가 쌓이는 동안 EKS 위의 알림 처리 워커 일부가 제대로 늘지 못했다."},"severity":"unknown","symptoms":["high-latency","autoscaler-misbehaving"],"timeline":{"detected_after":null,"resolved_after":"2h 39m"},"date_kind":"incident","detection":{"en":"Internal queue latency monitoring detected the rising notification delivery latency.","ko":"팀은 내부 큐 지연 모니터링으로 장애를 알아챘다. 공개 상태 페이지에는 20:20 UTC 에 첫 공지가 올라왔다."},"components":["prometheus"],"root_cause":"capacity","remediation":[{"text":{"en":"Moved the affected notification-processing workloads from EKS back to the ECS-based infrastructure","ko":"영향받은 워크로드를 EKS 에서 이전의 ECS 인프라로 옮기기 시작했다."}},{"text":{"en":"Adjusted scaling configuration and worker counts by hand","ko":"ECS 서비스가 전체 부하를 바로 받지 못해 엔지니어가 장애 중에 스케일링 설정과 워커 수를 손으로 조정했다."}},{"text":{"en":"Completed the rollback and scaled the remaining affected ECS services","ko":"두 번째 지연은 롤백을 마저 끝내고 남은 ECS 서비스를 늘려 해소했다."}},{"text":{"en":"Increased Prometheus storage capacity and recorded the change in infrastructure as code","ko":"Prometheus 저장 공간을 늘리고, 같은 변경을 인프라 코드에도 반영했다."}}],"action_items":[{"text":{"en":"Alert before Prometheus storage exhaustion can affect autoscaling","ko":"Prometheus 저장 공간이 바닥나 오토스케일링에 영향을 주기 전에 알림이 오도록 모니터링을 더한다."}},{"text":{"en":"Fix GitHub notification retry behaviour for a class of errors that could cause repeated retries","ko":"특정 종류의 오류에서 GitHub 알림 재시도가 되풀이되어 알림 지연을 늘리는 동작을 고친다."}},{"text":{"en":"Make the EKS-to-ECS rollback verify destination capacity, autoscaling configuration and traffic movement","ko":"EKS 에서 ECS 로 되돌리는 롤백 절차를 보강해, 롤백 전과 도중에 옮겨 갈 쪽의 용량, 오토스케일링 설정, 트래픽 이동을 확인하게 한다."}},{"text":{"en":"Review the CPU, memory and storage allocations of EKS control-plane dependencies such as KEDA and Karpenter","ko":"KEDA 와 Karpenter 를 비롯해 EKS 컨트롤 플레인이 의존하는 다른 구성 요소를 검토하고, CPU, 메모리, 저장 공간 할당이 운영 부하에 맞는지 확인한다."}},{"text":{"en":"Move customer-critical workloads to EKS more gradually, with clearer settling periods","ko":"앞으로 EKS 로 옮기는 순서와 속도를 다시 따져, 고객에게 중요한 워크로드는 더 천천히 옮기고 안정될 시간을 분명히 둔다."}},{"text":{"en":"Improve customer-level monitoring of notification delivery latency to detect customer-impacting regressions earlier","ko":"고객 단위로 알림 전달 지연을 보는 모니터링을 개선해 고객에게 영향을 주는 회귀를 더 일찍 잡는다."}},{"text":{"en":"Review which notification types sit on customers' scheduling or CI hot path and need tighter latency, separate queueing or specific alerting","ko":"어떤 알림 종류가 고객의 스케줄링이나 CI 의 핵심 경로에 있는지 검토한다. 그런 알림에는 더 엄격한 지연 기준, 별도 큐, 일반 알림 작업보다 구체적인 모니터링 경보가 필요한지 따진다."}},{"text":{"en":"Update the status page earlier when notification latency is likely to affect customer workflows","ko":"알림 지연이 고객의 작업 흐름에 영향을 줄 것 같으면 상태 페이지를 더 일찍 갱신한다."}},{"text":{"en":"Describe the customer-visible impact in status page updates, not only the affected internal service","ko":"상태 페이지에 영향받은 내부 서비스만이 아니라 고객이 겪는 영향을 분명하게 적는다."}},{"text":{"en":"Improve internal escalation for customers who report critical CI impact","ko":"장애를 다 파악하기 전이라도 심각한 CI 영향을 알려 오는 고객의 문의가 내부에서 빨리 올라가도록 에스컬레이션 경로를 개선한다."}}],"contributing":["no-alert-on-limit","partial-rollout","revert-did-not-restore","assumption-unverified","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"From 20:01 UTC on 28 May 2026, Buildkite build and job notifications (GitHub commit status, email, Slack and webhook notifications) reached a subset of customers late. Internal queue latency monitoring showed the delay as queues grew while notification-processing workers stayed underprovisioned.\n\nFor customers who feed Buildkite notifications into other CI, merge or deployment systems, the delay also held up those workflows, and some customers saw secondary or longer effects depending on the notification type, retry behaviour or integration involved. Notification latency recovered for most customers by 21:00 UTC.\n\nA second, shorter delay hit a subset of customers from 22:12 to 22:40 UTC, after the first recovery, when EKS workloads that were still serving traffic were scaled down before their ECS replacements had fully scaled up.","ko":"2026-05-28 20:01 UTC 부터 알림 처리 워커가 모자라 Buildkite 의 알림 전달 지연이 늘었다. 내부 큐 지연 모니터링이 이를 잡았다.\n\n늦어진 알림은 GitHub 커밋 상태, 이메일, Slack, 웹훅 알림이었다. 이 알림을 다른 CI 나 배포 시스템의 입력으로 쓰는 고객은 그 뒤의 CI, 병합, 배포 흐름까지 늦어졌다. 알림 종류, 재시도 동작, 연동 방식에 따라 영향이 더 길게 남은 고객도 있었다.\n\n대부분 고객의 지연은 21:00 UTC 에 풀렸지만, 22:12 부터 22:40 UTC 까지 일부 고객에게 지연이 다시 나타났다.\n\n팀은 처음에 영향받은 워크로드를 EKS 에서 이전의 ECS 인프라로 되돌렸다. 그러나 되돌아갈 ECS 서비스가 전체 부하를 바로 받을 준비가 되어 있지 않아 회복이 예상보다 늦었다.\n\n공개 상태 페이지에는 20:20 UTC 에 일부 고객의 빌드와 작업 알림이 늦어지고 있어 조사 중이라는 공지가 처음 올라왔다."},"updated_at":"2026-11-14T12:34:11.777514Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0470","org_slug":"buildkite"}