{"id":"IL-0561","org":"DigitalOcean","date":"2026-08-24","docs":[],"title":{"en":"DigitalOcean's Cloud Control Panel and Public API returned up to 25% errors in two windows as authorization timed out","ko":"DigitalOcean 의 Cloud Control Panel 과 공개 API 에서 두 차례에 걸쳐 요청이 최대 25% 실패했다"},"domain":["database"],"impact":{"scope":"Cloud Control Panel, Public API, Kubernetes cluster authentication, Container Registry and Serverless / AI Inference endpoints failed requests at about 10% on average and 25% at peak; Droplets, network routing and Volumes were not affected","users":"fewer than 2% of active customer accounts saw at least one failed API or Control Panel request","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.digitalocean.com/incidents/4qwm6pzlx1z3","kind":"official-status","archived":"https://web.archive.org/web/20261015001907/https://status.digitalocean.com/incidents/4qwm6pzlx1z3"}],"summary":{"en":"DigitalOcean was migrating the database layer that supports its identity, authentication and authorization services as planned infrastructure work. At 16:56 UTC the migration made a critical authorization query much slower. Several upstream services reacted to the slow query with automated hedged retries, which amplified the requests reaching the authentication service. The extra requests built a queue larger than the authentication service pool could process, and requests along the authorization path timed out in a cascade. Requests to the Cloud Control Panel, the Public API and other management control planes failed, while the data plane stayed up because established connections do not depend on the authorization path.\n\nTo end the first window, engineers sent authorization traffic over a single healthy processing path and switched off hedging for the main callers, and service came back. At 21:30 traffic was returned to the standard multipath routing. The query was still slow, and callers that did not hedge still retried, so the queue saturated again and the second window began. Teams then disabled retry and amplification behaviour in the remaining affected services and added read capacity for the slow query, and the service was stable from 23:09. The database migration was completed afterwards, and no customer data was lost.","ko":"2026년 8월 24일 DigitalOcean 은 아이덴티티, 인증, 인가 서비스를 받치는 데이터베이스 계층을 계획에 따라 이전하고 있었다. 16:56 UTC 에 핵심 인가 쿼리 하나가 평소 기준보다 훨씬 느려졌다. 쿼리 지연이 늘자 여러 상위 서비스가 자동으로 hedged retry 를 보냈다. 이렇게 불어난 요청이 인증 서비스 풀의 처리량을 넘어서 큐가 쌓였고, 인가 경로 전체로 요청 타임아웃이 연쇄로 번졌다.\n\n첫 구간에서 엔지니어들은 재시도 설정을 조정하고, 인가 트래픽을 정상인 처리 경로 하나로 몰고, 주요 호출자의 hedging 을 잠시 껐다. 18:52 에 서비스가 돌아왔다. 21:30 에 트래픽을 평소의 여러 경로 구성으로 되돌리자, 남아 있던 쿼리 지연과 hedging 을 끄지 않은 호출자의 재시도가 겹쳐 큐가 다시 포화됐고 두 번째 구간이 시작됐다. 팀은 나머지 영향받은 서비스에서도 재시도와 요청 증폭 동작을 끄고, 느린 쿼리에 읽기 용량을 더했다. 23:09 에 서비스가 안정됐다.\n\n두 구간에서 인증된 요청의 평균 약 10% 가 실패했고 최고 오류율은 25% 였다. 활성 고객 계정의 2% 미만이 API 나 Cloud Control Panel 요청 실패를 한 번 이상 겪었다. Droplet, 네트워크 라우팅, Volumes 는 영향을 받지 않았고 데이터 손실은 없었다. 데이터베이스 이전은 끝까지 마쳤다."},"trigger":{"en":"A planned migration of the database layer behind DigitalOcean's identity, authentication and authorization services made one critical authorization query run much slower than its historical baseline.","ko":"아이덴티티, 인증, 인가 서비스를 받치는 데이터베이스 계층을 계획에 따라 이전하는 인프라 작업을 하던 중이었다. 이 이전 작업 때문에 핵심 인가 쿼리 하나의 실행 지연이 늘었다."},"severity":"unknown","symptoms":["high-error-rate","high-latency"],"timeline":{"detected_after":"2m","resolved_after":"6h 13m"},"date_kind":"incident","detection":{"en":"Automated monitoring detected abnormal error rates and latency at 16:58 UTC, two minutes after the authorization query slowed down.","ko":"16:58 UTC 에 자동 모니터링이 비정상적인 오류율과 지연을 잡아냈다. 보고서는 영향이 시작되고 5분 안에 감지했다고 적었다."},"components":["database","identity-service"],"root_cause":"config-change","remediation":[{"text":{"en":"Rerouted authorization traffic onto a single healthy processing path","ko":"인가 트래픽을 정상으로 동작하는 처리 경로 하나로 몰아 보냈다."}},{"text":{"en":"Temporarily disabled hedged retries for the primary callers","ko":"주요 호출자의 hedging 을 잠시 껐다."}},{"text":{"en":"Disabled the retry and amplification behaviour across the remaining affected services","ko":"두 번째 구간에서 나머지 영향받은 서비스 전체의 재시도와 요청 증폭 동작을 껐다."}},{"text":{"en":"Added read capacity for the slow authorization query","ko":"느린 인가 쿼리를 받을 읽기 용량을 더했다."}}],"action_items":[{"text":{"en":"Deploy circuit breakers in upstream services that detect a degraded downstream dependency and suppress hedged requests and retries","ko":"상위 서비스 전반에 자동 서킷 브레이커를 배포했다. 서킷 브레이커는 하위 의존 서비스가 나빠진 것을 감지하면 hedged retry 와 재시도 증폭을 자동으로 막는다."}},{"text":{"en":"Audit the architecture so retry suppression and circuit breaking are enforced the same way in every control plane service","ko":"모든 컨트롤 플레인 서비스에 재시도 억제와 서킷 브레이커가 똑같이 적용되는지 아키텍처 전반을 점검하는 작업을 마쳤다."}},{"text":{"en":"Add fast-fail load shedding so request queues do not saturate while a dependency is slow","ko":"의존 서비스가 느려질 때 요청 큐가 포화되지 않도록 요청을 빠르게 실패시키는 로드 셰딩을 넣었다."}},{"text":{"en":"Add telemetry alerts that spot queues backing up before customers are affected","ko":"고객이 영향을 받기 전에 큐가 쌓이기 시작한 것을 알아채는 텔레메트리 알림을 더했다."}},{"text":{"en":"Let critical authorization components run in a degraded mode on asynchronous, eventually consistent database replicas when the primary database is slow","ko":"주 데이터베이스가 느려지면 핵심 인가 구성 요소가 기능을 줄인 모드로 동작하도록 설정했다. 이 모드에서는 비동기로 갱신되는 최종 일관성 복제본을 읽는다."}}],"contributing":["retry-storm","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"From 16:56 UTC on 24 August 2026, requests to DigitalOcean's Cloud Control Panel, Public API and the product management systems that depend on them failed at elevated rates. Automated monitoring flagged abnormal error rates and latency at 16:58. Running Droplets, network routing and block storage Volumes kept working.\n\nThe status page told users to expect elevated 5xx errors for all API requests, including creates for various products, and said cloud.digitalocean.com might not load. Serverless Inference users saw 403 and 503 errors on their API requests. The affected management control planes were the Cloud Control Panel, the Public API, Kubernetes cluster authentication, Container Registry and the Serverless / AI Inference endpoints.\n\nThe errors came in two windows that added up to 3.5 hours of degradation within about 6 hours. The first window ran from 16:56 until about 18:52, when operators had tuned retries and moved requests onto one healthy service instance. At 21:30, moving traffic back to the normal production pattern brought the same saturation back, and at 22:27 the status page reported a recurrence. The second window lasted until 23:09 and reached the peak error rate of 25%. Across both windows about 10% of authenticated requests failed on average.","ko":"2026년 8월 24일 16:56 UTC 부터 DigitalOcean 의 Cloud Control Panel, 공개 API, 그리고 이 둘에 기대는 제품 관리 시스템에서 요청 오류율이 올라갔다. 여러 제품의 생성 요청을 포함한 모든 API 요청에서 5xx 오류가 늘었고, 사용자가 cloud.digitalocean.com 에 들어가지 못하기도 했다.\n\n영향을 받은 관리 영역은 Cloud Control Panel, 공개 API, Kubernetes 클러스터 인증, Container Registry, Serverless 와 AI Inference 엔드포인트였다. Serverless Inference 사용자는 API 를 호출하거나 해당 서비스에 접근할 때 403 과 503 오류를 받을 수 있었다.\n\n오류는 6시간 동안 두 구간에 나뉘어 나타났고, 실제로 서비스가 나빴던 시간은 합쳐서 3.5시간이었다. 첫 구간은 16:56 에 시작해 18:52 에 끝났다. 그사이 18:33 에는 지연과 오류율이 조금 나아졌고 일부 사용자는 Cloud Control Panel 에 다시 들어갈 수 있을 것이라는 공지가 상태 페이지에 올라왔다. 21:30 에 트래픽을 평소 구성으로 되돌리자 같은 포화가 다시 일어나 두 번째 구간이 시작됐고, 23:09 에 끝났다. 두 구간을 합친 평균 실패율은 인증된 요청의 약 10% 였고, 최고 오류율 25% 는 두 번째 구간에서 나왔다.\n\n실행 중인 Droplet, 네트워크 라우팅, 블록 스토리지인 Volumes 는 사고 내내 정상으로 동작했다. 이미 맺어진 연결은 문제가 난 인가 경로를 거치지 않기 때문이다."},"updated_at":"2026-11-14T12:34:20.967875Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0561","org_slug":"digitalocean"}