{"id":"IL-0548","org":"Buildkite","date":"2026-05-20","docs":[],"title":{"en":"Buildkite's EKS Prometheus server was killed for memory again and again, so services stopped scaling and jobs lagged","ko":"EKS 의 Prometheus 가 거듭 죽으며 Buildkite 의 알림 전달과 빌드 디스패치가 지연됐다"},"domain":["kubernetes","aws","observability"],"impact":{"scope":"Elevated latency in notification delivery (GitHub commit status, email, Slack and webhook notifications), build dispatch and metrics services","users":"A subset of Buildkite customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://www.buildkitestatus.com/incidents/3vngjcnbkycl","kind":"official-status","archived":"https://web.archive.org/web/20260613144311/https://www.buildkitestatus.com/incidents/3vngjcnbkycl"}],"summary":{"en":"Buildkite was moving its production workloads from AWS Fargate to AWS EKS in small batches so it could check stability along the way. On 20 May 2026, between 15:42 and 17:33, autoscaling raised the number of pods that the EKS Prometheus server tracked, and Prometheus came to need more memory than the host it ran on had. The host killed the Prometheus process and the Kubernetes control plane restarted it shortly after, but Prometheus soon used up the host's memory again and the cycle repeated. Each time, the metrics used for application autoscaling were unavailable, so the affected services were not scaled up and notification delivery, build dispatch and metrics were delayed.\n\nThe on-call team followed prepared documentation to move the load of the affected services back to Fargate, and most customers had fully recovered from 16:49. A handful of customers with a very large backlog had to be scaled up further by hand, and all customers had recovered by 17:33. Buildkite then made the system nodes larger, gave Prometheus higher requests and limits, set missing requests and limits on all new EKS resources and added monitoring for EKS pod and node health, and later moved the services back to EKS, where scaling went well past the limits met in this incident.","ko":"Buildkite 는 운영 워크로드의 컴퓨팅 기반을 AWS Fargate 에서 AWS EKS 로 옮기고 있었다. 서비스는 안정성을 확인하며 작은 묶음으로 옮겼다.\n\n15:42 부터 17:33 사이에 EKS 의 Prometheus 서버가 쓰려는 메모리가 실행 중인 호스트의 메모리보다 많아졌다. 오토스케일링으로 Prometheus 가 추적하는 파드 수가 늘었고, 그만큼 Prometheus 서버의 메모리 요구량이 커졌다. 호스트가 Prometheus 서버 프로세스를 죽였고 쿠버네티스 컨트롤 플레인이 곧 다시 띄웠다. 그사이 애플리케이션 오토스케일링에 쓰는 지표가 없어 영향을 받은 서비스들이 확장되지 않았고, 그 결과 지연이 생겼다. Prometheus 는 재시작 직후 다시 호스트 메모리를 넘었고 같은 순환이 되풀이됐다.\n\n당번 팀은 미리 마련한 문서를 따라 영향을 받은 서비스의 부하를 Fargate 로 되돌렸다. 대부분의 고객은 16:49 부터 완전히 회복됐다. 지연 동안 백로그가 크게 쌓인 일부 고객은 손으로 더 확장해야 했고, 17:33 에 모든 고객이 완전히 회복됐다. Buildkite 는 그 뒤 이 서비스들을 모두 다시 EKS 로 옮겼고, 이번 장애에서 부딪힌 한계를 훨씬 넘는 규모까지 확장이 잘 되는 것을 확인했다."},"trigger":{"en":"Autoscaling during Buildkite's migration of production services from AWS Fargate to AWS EKS raised the number of pods that Prometheus tracked, and with it the memory the Prometheus server needed.","ko":"오토스케일링으로 Prometheus 가 추적하는 파드 수가 늘었고, 그만큼 Prometheus 서버의 메모리 요구량이 커졌다."},"severity":"unknown","symptoms":["high-latency","oom-killed","monitoring-down","autoscaler-misbehaving"],"timeline":{"detected_after":null,"resolved_after":"1h 51m"},"date_kind":"incident","detection":null,"components":["prometheus","memory-limit","node-pool"],"root_cause":"capacity","remediation":[{"text":{"en":"Moved the load of the affected services back to AWS Fargate by following prepared documentation","ko":"당번 팀이 미리 마련한 문서를 따라 영향을 받은 서비스의 부하를 Fargate 로 되돌렸고, 대부분의 고객이 16:49 부터 완전히 회복됐다."}},{"text":{"en":"Scaled up the services of a few customers with very large backlogs further by hand","ko":"지연 동안 백로그가 크게 쌓인 일부 고객의 처리 규모를 손으로 더 늘렸고, 17:33 에 모든 고객이 완전히 회복됐다."}}],"action_items":[{"text":{"en":"Upsize the underlying system nodes","ko":"시스템 노드의 크기를 키웠다."}},{"text":{"en":"Set higher requests and limits for the Prometheus server so it can handle more load","ko":"Prometheus 서버가 더 많은 제품 부하를 감당하도록 requests 와 limits 를 높였다."}},{"text":{"en":"Review all new EKS resources and set any missing requests and limits","ko":"새 EKS 리소스 전부를 검토해 빠진 requests 와 limits 를 채웠다. EKS 가 뜻하지 않은 리소스 경합을 막으려면 이 정보가 모두 있어야 한다."}},{"text":{"en":"Add observability and monitors for EKS pod and node health","ko":"다음 장애에서 근본 원인을 빨리 찾도록 EKS 파드와 노드 상태의 관측 수단과 모니터를 더했다."}}],"contributing":["no-resource-limits"],"recurrence_of":null,"symptoms_text":{"en":"On 20 May 2026 a subset of Buildkite customers saw delays in notification delivery, build dispatch and the metrics services. The status page first reported delays to notifications for all customers and later narrowed it to a subset of customers.\n\nThe affected notifications were GitHub commit status, email, Slack and webhook notifications. Behind the delays, the Prometheus server on Buildkite's EKS cluster needed more memory than its host had, the host killed the process, and the Kubernetes control plane restarted it. While Prometheus was down, the metrics that drove application autoscaling were missing, so the services did not scale up. Soon after each restart Prometheus ran out of the host's memory again and the cycle repeated, from 15:42 to 17:33.\n\nA few customers built up such a large backlog during the slow period that their services had to be scaled up further by hand.","ko":"일부 Buildkite 고객에게 알림 전달, 빌드 디스패치, 지표 서비스의 지연이 커졌다. 상태 페이지에는 2026년 5월 20일 16:40 UTC 에 모든 고객의 알림 지연을 조사한다는 글이 올라왔다.\n\n15:42 부터 EKS 의 Prometheus 서버가 쓰려는 메모리가 실행 중인 호스트의 메모리보다 많아졌다. 호스트가 Prometheus 서버 프로세스를 죽였고 쿠버네티스 컨트롤 플레인이 곧 다시 띄웠지만, Prometheus 는 재시작 직후 다시 호스트 메모리를 넘었고 같은 일이 되풀이됐다.\n\nPrometheus 가 내려가 있는 동안 애플리케이션 오토스케일링에 쓰는 지표가 없었다. 그래서 영향을 받은 서비스들이 확장되지 않았고, 그 결과 지연이 생겼다.\n\n상태 페이지는 17:06 UTC 에 알림 지연이 일부 고객에게만 있다고 알렸다. 영향을 받은 알림은 GitHub Commit Status Notifications, Email Notifications, Slack Notifications, Webhook Notifications 였다."},"updated_at":"2026-11-14T12:34:19.761313Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0548","org_slug":"buildkite"}