{"id":"IL-0284","org":"Cloudflare","date":"2025-06-12","docs":[],"title":{"en":"Workers KV failed 90.22% of requests in a third-party storage outage, breaking Access, WARP and many Cloudflare products","ko":"Workers KV 의 저장소 인프라가 멈춰 KV 에 기대는 Access, WARP, Gateway, 대시보드 같은 Cloudflare 서비스 여럿이 2시간 28분 동안 전 세계에서 실패했다"},"domain":["database"],"impact":{"scope":"Workers KV failed 90.22% of requests; Access, Gateway, WARP, Dashboard, Challenges and Turnstile, Browser Isolation, Images, Stream, Realtime, Workers AI, Pages and Workers Assets, AutoRAG, Durable Objects, D1, Queues and Event Notifications, AI Gateway, parts of the CDN, Workers, Workers Builds, Browser Rendering and Zaraz were impaired; no data was lost","users":"all Cloudflare customers using the affected services","region":"global"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Cloudflare holds itself responsible for its choice of dependencies and how it architects around them, even when a vendor failure was the trigger. Building many products on Workers KV normally makes them more robust than separate storage services would, but here the cascading failure of Workers KV made the outage worse and widened its blast radius.","ko":"서드파티 공급자의 장애가 직접 원인이었지만 Cloudflare 는 어떤 의존을 고르고 그 의존을 감안해 시스템을 어떻게 설계하는지가 자기 책임이라고 밝혔다. 많은 서비스가 각자 저장소를 만들지 않고 Workers KV 에 기대는 것은 평소에는 서비스를 튼튼하게 하지만, 이번에는 KV 의 실패가 연쇄로 번져 피해 범위를 크게 넓혔다."},"related":[],"sources":[{"url":"https://blog.cloudflare.com/cloudflare-service-outage-june-12-2025/","kind":"blog","archived":"https://web.archive.org/web/20261104233046/https://blog.cloudflare.com/cloudflare-service-outage-june-12-2025/"}],"summary":{"en":"Workers KV is built as a \"coreless\" service that runs independently in each Cloudflare location, but it relies on a central data store as the source of truth, and part of that storage infrastructure is backed by a third-party cloud provider. Workers KV was being moved to more resilient infrastructure for its central store, including a migration to Cloudflare R2, and had removed a storage provider during that re-architecture; Cloudflare says there was a gap in coverage, which this incident exposed. Cloudflare builds its products on its own platform, so many of them rely on Workers KV for configuration, authentication and asset delivery, and SQLite-backed Durable Objects and D1 share the same underlying storage. When the third-party provider had an outage, cold reads and writes to the KV namespaces used across Cloudflare failed completely, and the failure cascaded into every product built on Workers KV. Magic Transit, Magic WAN, DNS, Cache, the proxy and WAF were not directly affected, and no data was lost.\n\nThe incident started at 17:52 UTC with failing WARP device registrations. At 18:06 the separate service incidents were merged once the shared cause was found, and at 18:21 the priority was raised from P1 to P0. From 18:43 Access worked with the Workers KV team on moving to a different backing datastore in case the storage stayed down, and from 19:45 teams worked on a Workers KV release against an alternative datastore. At 19:09 Gateway began degrading rules that referenced identity or device posture, and at 19:32 Access and Device Posture force-dropped identity and device posture requests to shed load on Workers KV. Turnstile and Challenges kill switches were turned on so visitors were not blocked; while they were on, siteverify could redeem valid tokens more than once. At 20:23 services began to recover with the storage infrastructure, at 20:25 Access and Device Posture resumed calling Workers KV, and at 20:28 Service Level Objectives were back at pre-incident levels. Cloudflare gave the outage's length as 2 hours and 28 minutes.","ko":"Workers KV 는 전 세계 거점마다 따로 도는 서비스로 만들었지만, 데이터의 기준이 되는 중앙 저장소 하나에 기대고 있었다. 이 저장소의 일부는 서드파티 클라우드 공급자가 받치고 있었다. Cloudflare 는 자기 플랫폼 위에 서비스를 짓는다는 원칙에 따라 많은 제품이 설정, 인증, 자산 전달을 Workers KV 에 맡겼다. Workers KV 는 데이터 일관성 문제를 막고 데이터 저장 위치 요건을 지원하려고 백엔드를 Cloudflare R2 로 옮기는 중이었고, 그 과정에서 저장소 공급자 하나를 뺐다. Cloudflare 는 이 전환 과정에 빈틈이 있었고 이번 장애가 그 빈틈을 드러냈다고 밝혔다.\n\n2025년 6월 12일 이 공급자에 장애가 나자 KV 네임스페이스의 콜드 읽기와 쓰기가 전부 멈췄다. 17:52 UTC 에 WARP 팀이 새 기기 등록 실패를 보고 장애를 선언했고, 18:05 에 Access 와 여러 서비스의 SLO 알림이 울렸다. 18:06 에 팀은 Workers KV 를 쓸 수 없게 된 것이 공통 원인임을 알고 서비스별 장애를 하나로 합쳐 P1 으로 올렸고, 18:21 에 영향의 크기를 보고 P0 으로 올렸다. Access, Gateway, WARP, 대시보드, Challenges 와 Turnstile, Workers AI, Stream, Pages, Queues 같은 제품이 KV 를 통해 함께 실패했고, KV 와 같은 저장소를 쓰는 Durable Objects 와 D1 도 오류를 냈다. 이 연쇄로 피해 범위가 크게 넓어졌다. 데이터는 잃지 않았고 Magic Transit, Magic WAN, DNS, Cache, 프록시, WAF 는 직접 영향을 받지 않았다.\n\n팀들은 저장소가 계속 멈출 때를 대비해 Access 를 다른 저장소로 옮길 방법을 찾았다. Gateway 는 신원과 Device Posture 를 쓰는 규칙을 단계적으로 약하게 만들었다. Access 와 Device Posture 는 KV 부하를 줄이려고 요청을 강제로 버렸다. 다른 저장소를 쓰는 Workers KV 릴리스도 준비했다. 20:23 에 저장소 인프라가 회복되면서 서비스들이 돌아오기 시작했고, 20:25 에 Access 와 Device Posture 가 KV 호출을 되살렸으며, 20:28 에 SLO 가 장애 전 수준으로 돌아왔다. Cloudflare 는 장애가 2시간 28분 이어졌다고 밝혔다."},"trigger":{"en":"Part of the storage infrastructure behind Workers KV is backed by a third-party cloud provider, and that provider had an outage. Workers KV could then no longer serve cold reads or writes from its central data store.","ko":"Workers KV 의 중앙 저장소 일부를 받치던 서드파티 클라우드 공급자에 장애가 났고, KV 가 원본 저장소에서 값을 읽고 쓰지 못하게 됐다."},"severity":"unknown","symptoms":["high-error-rate","service-unavailable","credentials-unavailable"],"timeline":{"detected_after":null,"resolved_after":"2h 36m"},"date_kind":"incident","detection":{"en":"The WARP team saw registrations of new devices failing at 17:52 UTC and declared an incident. At 18:05 the Access team received an alert on a rapid increase in error rates and Service Level Objective alerts fired across several teams; at 18:06 the incidents were combined once Workers KV unavailability was identified as the shared cause.","ko":"17:52 UTC 에 Cloudflare WARP 팀이 새 기기 등록이 실패하는 것을 보고 조사를 시작해 장애를 선언했다. 18:05 에 Access 팀이 오류율 급증 알림을 받았고, 여러 서비스의 SLO 가 목표 아래로 떨어져 팀마다 알림이 울렸다. 18:06 에 Workers KV 를 쓸 수 없게 된 것이 공통 원인임을 찾아 서비스별 장애를 하나로 합쳤다."},"components":["database"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Activated the Challenges and Turnstile kill switches so visitors were not blocked","ko":"Challenges 와 Turnstile 의 siteverify 호출을 끄는 킬 스위치를 켜 방문자가 막히지 않게 했다. 킬 스위치를 켜 둔 동안에는 siteverify API 가 유효한 토큰 하나를 여러 번 받아들일 수 있었다. 봇 탐지는 영향을 받지 않았다."}},{"text":{"en":"Degraded Gateway rules that referenced identity or device posture state to remove the Workers KV dependency","ko":"19:09 UTC 에 Zero Trust Gateway 가 신원이나 Device Posture 상태를 참조하는 규칙을 단계적으로 약하게 만들어 Workers KV 의존을 덜었다."}},{"text":{"en":"Force-dropped Access identity and device posture requests to shed load on Workers KV","ko":"19:32 UTC 에 Access 와 Device Posture 가 서드파티 서비스가 돌아올 때까지 신원과 Device Posture 요청을 강제로 버려 Workers KV 의 부하를 줄였다."}},{"text":{"en":"Worked on a Workers KV release against an alternative backing datastore in case the storage stayed down","ko":"저장소가 계속 멈출 때를 대비해, 다른 저장소를 쓰는 Workers KV 릴리스를 배포하고 핵심 서비스가 설정 데이터를 그 저장소에 쓰게 할 방법을 계속 준비했다."}},{"text":{"en":"Restored Access and Device Posture calls to Workers KV once the third-party service was back","ko":"20:25 UTC 에 서드파티 서비스가 회복되자 Access 와 Device Posture 가 Workers KV 호출을 되살렸다."}}],"action_items":[{"text":{"en":"Avoid singular dependencies on storage infrastructure that Cloudflare does not own","ko":"Cloudflare 가 소유하지 않은 저장소 인프라 하나에만 기대는 구조를 없앤다."}},{"text":{"en":"Improve the ability to recover critical services, including Access, Gateway and WARP","ko":"Access, Gateway, WARP 같은 핵심 서비스를 복구하는 능력을 높인다."}},{"text":{"en":"Add redundancy to Workers KV's storage infrastructure and remove the dependency on any single provider","ko":"Workers KV 저장소 인프라의 이중화를 강화해 어느 한 공급자에도 기대지 않게 하는 작업을 앞당긴다. 장애 중에 이미 핵심 KV 네임스페이스를 자체 인프라로 옮기고 백필하는 일을 시작했다."}},{"text":{"en":"Make each affected product resilient to the loss of any single point of failure, third-party dependencies included","ko":"이번 장애로 영향을 받은 제품마다 피해 범위를 줄이는 단기 조치를 적용해, 서드파티 의존을 포함한 어떤 단일 장애 지점이 멈춰도 제품이 버티게 한다."}},{"text":{"en":"Build tooling to re-enable namespaces progressively during storage incidents, so services come back without overloading Cloudflare's own infrastructure","ko":"저장소 인프라 장애 때 네임스페이스를 차례로 다시 켜는 도구를 만들어, 캐시를 다시 채우는 동안 Access 와 WARP 같은 핵심 의존 서비스가 자체 인프라에 서비스 거부를 일으키지 않고 올라오게 한다."}}],"contributing":["single-point-of-failure","blast-radius-too-wide","circular-dependency","retry-storm"],"recurrence_of":null,"symptoms_text":{"en":"At 17:52 UTC on 12 June 2025, Cloudflare's WARP team saw registrations of new devices failing and declared an incident. Minutes later the Cloudflare Access team got an alert on a rapid rise in error rates, and Service Level Objectives for several other services fell below target. All of them shared one cause: Workers KV was unavailable.\n\nWorkers KV failed 90.22% of requests. Any key that was not in the cache and had to be read from Workers KV's origin storage backends failed with response code 503 or 500, while requests served from the cache still returned 200 or 404. Access, which keeps application and policy configuration and user identity in Workers KV and fails closed, failed 100% of identity-based logins. Gateway could not evaluate identity-based DNS over HTTPS rules, and users of the Gateway proxy, egress and TLS decryption could not connect. No new WARP clients could connect or sign up, and the WARP emergency disconnect override was itself unavailable because it also depends on Workers KV. Dashboard logins failed, the siteverify API of Challenges and Turnstile failed or timed out, all Workers AI inference requests failed, Stream errors exceeded 90%, Pages errors peaked at about 100%, Queues were unavailable, AI Gateway errors peaked at 97%, and SQLite-backed Durable Objects and D1, which share the same storage infrastructure, peaked at 22% errors.\n\nThe outage also spread to the CDN. Registration requests from Zero Trust clients increased sharply and loaded several Cloudflare locations, and automated traffic management moved CDN traffic to nearby locations. Part of the traffic was not rerouted as expected and saw elevated latency, HTTP 499 errors and HTTP 503 errors in São Paulo, Philadelphia, Atlanta and Raleigh. When the storage infrastructure started to recover at 20:23, a non-negligible error rate and infrastructure rate limits remained while services repopulated their caches.","ko":"17:52 UTC 에 WARP 팀이 새 기기 등록이 실패하는 것을 보고 장애를 선언했다. 18:05 에 Cloudflare Access 팀이 오류율 급증 알림을 받았고, 여러 서비스의 SLO 가 목표 아래로 떨어져 팀마다 알림이 울렸다.\n\nWorkers KV 는 요청의 90.22% 가 실패했다. 캐시에 없어 원본 저장소 백엔드에서 값을 가져와야 하는 키는 응답 코드 503 이나 500 으로 실패했다. 나머지 요청은 Workers KV 캐시에서 응답해 200 과 404 로 성공했다.\n\nAccess 는 Self-Hosted, SaaS, Infrastructure 모든 애플리케이션 종류에서 신원 기반 로그인이 100% 실패했다. Access 는 정책 설정이나 사용자 신원을 가져오지 못하면 접근을 막도록 설계됐기 때문이다. SCIM 서비스는 신원 공급자의 요청에 500 으로 응답했다. Gateway 는 신원 기반 규칙이 걸린 DoH 쿼리가 실패했고, Gateway 프록시, egress, TLS 복호화를 쓰는 사용자는 연결도 등록도 하지 못했다. WARP 에서는 새 클라이언트가 연결하거나 가입하지 못했고, 비상 연결 해제 기능도 쓸 수 없었다.\n\n대시보드에서는 로그인이 되지 않았고 기존 세션도 대부분 쓸 수 없었다. 아이디와 비밀번호 로그인은 Turnstile 이, Google 로그인은 KV 가, SSO 로그인은 Access 가 멈춰 실패했다. Challenges 와 Turnstile 의 siteverify API 요청은 실패와 타임아웃이 잦았다.\n\n다른 제품들도 같은 의존 때문에 실패했다. Workers AI 는 추론 요청이 전부 실패했고, Stream 은 오류율이 90% 를 넘었으며 Stream Live 는 100% 였다. Pages 는 오류율이 약 100% 까지 올랐고 빌드가 끝나지 않았다. KV 와 같은 저장소를 쓰는 SQLite 기반 Durable Objects 와 D1 은 평균 오류율이 22% 까지 올랐다. AI Gateway 는 오류율이 97% 까지 올랐고, Queues 는 메시지를 넣지도 꺼내지도 못했으며, Realtime TURN 은 오류율이 100% 가까이 됐다. 새 Workers Builds 는 18:03 부터 100% 실패했고, Zaraz 는 요청이 100% 영향을 받았다.\n\nZero Trust 클라이언트의 등록 요청이 크게 늘어 여러 Cloudflare 거점에 부하가 걸렸다. 자동 트래픽 관리가 CDN 트래픽을 가까운 거점으로 돌렸지만 트래픽 일부는 예상대로 옮겨지지 않았다. 이 때문에 São Paulo, Philadelphia, Atlanta, Raleigh 에서 CDN 요청의 지연이 늘고 HTTP 499 와 HTTP 503 오류가 났다.\n\n20:23 에 저장소 인프라가 회복되면서 서비스들이 돌아오기 시작했지만, 서비스들이 한꺼번에 캐시를 다시 채우느라 한동안 오류가 이어졌고 인프라의 rate limit 에도 걸렸다."},"updated_at":"2026-11-14T12:33:53.875100Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0284","org_slug":"cloudflare"}