Cloudflare service outage June 12, 2025
Authors: Jeremy Hartman, CJ Desai
Overview
On June 12, 2025, Cloudflare experienced a significant service outage lasting 2 hours and 28 minutes. The incident affected numerous critical services including Workers KV, WARP, Access, Gateway, Images, Stream, Workers AI, Turnstile, Challenges, AutoRAG, Zaraz, and portions of the Cloudflare Dashboard.
The root cause was a failure in the underlying storage infrastructure used by Workers KV, which serves as a critical dependency for many Cloudflare products. The company states: “Part of this infrastructure is backed by a third-party cloud provider, which experienced an outage today and directly impacted availability of our KV service.”
Cloudflare emphasizes that while the third-party vendor failure triggered the outage, they take full responsibility: “we are ultimately responsible for our chosen dependencies and how we choose to architect around them.” The incident was not caused by a security event, no data was lost, and services like Magic Transit, Magic WAN, DNS, Cache, proxy, and WAF were unaffected.
Detailed Impact Assessment
A comprehensive table documents the specific impact on each service:
Workers KV experienced a 90.22% request failure rate for operations requiring retrieval from origin storage backends. Cached requests continued functioning normally.
Access failed 100% of identity-based logins across all application types. The service relies on Workers KV for configuration and user identity storage. Service-token and IP-based authentication remained operational.
Gateway saw most DNS queries function normally, but DNS-over-HTTPS queries with identity-based rules failed. Users requiring new authentication sessions experienced disruptions. Gateway proxy, egress, and TLS decryption services could not function.
WARP could not register new devices or enable signups. Existing sessions routed through Gateway experienced disruptions due to policy evaluation failures.
Dashboard login failures affected standard credentials, Google sign-in via OIDC, and SSO authentication. The Cloudflare v4 API remained operational.
Challenges and Turnstile experienced high failure rates for siteverify API requests. Kill switches were activated to prevent user blocking, though this temporarily allowed valid tokens to be redeemed multiple times.
Browser Isolation sessions via Gateway were completely unavailable. Link-based isolation experienced disruptions for both existing and new sessions.
Images saw 100% failure for batch uploads at peak impact, with overall delivery declining to 97% success.
Stream exceeded 90% error rates as video playlists could not be served. Live streams saw 100% failures, while uploads remained unaffected.
Realtime services experienced near 100% error rates for TURN services, with SFU unable to create new sessions.
Workers AI inference requests failed completely due to KV dependency for configuration distribution.
Pages & Workers Assets saw error rates peak to approximately 100%, preventing build completion.
AutoRAG became unavailable due to Workers AI dependencies.
Durable Objects and D1 experienced average error rates peaking at 22%, dropping to 2% during recovery.
Queues & Event Notifications message operations were entirely unavailable.
AI Gateway peaked at 97% error rates until dependencies recovered.
CDN experienced reduced automated traffic management efficacy, with rerouting failures in São Paulo, Philadelphia, Atlanta, and Raleigh locations causing elevated latency and HTTP 499/503 errors.
Workers/Workers for Platforms saw peak error rates of approximately 2% and 10% respectively.
Workers Builds (CI/CD) experienced 100% failure rates due to Access unavailability preventing source code management push events.
Browser Rendering saw 100% impact to both REST API and Workers Browser Binding requests.
Zaraz experienced 100% request impact, with configuration updates failing during the incident.
Technical Background
Workers KV operates as a “coreless” service designed to run independently across worldwide locations without single points of failure. However, the service depends on a central data store serving as the source of truth. This central storage failure caused a complete outage for cold reads and writes across KV namespaces used by Cloudflare services globally.
The company explains: “Workers KV removed a storage provider as we worked to re-architect KV’s backend, including migrating it to Cloudflare R2, to prevent data consistency issues (caused by the original data syncing architecture), and to improve support for data residency requirements.” This architectural transition created a coverage gap that the incident exposed.
Cloudflare notes that their principle of building services on their own platform, while normally beneficial, amplified the cascading impact in this case.
Incident Timeline
| Time (UTC) | Event |
|---|---|
| 17:52 | Incident begins as WARP team observes device registration failures |
| 18:05 | Access team receives alert on error rate spikes; multiple service-level objectives drop below targets |
| 18:06 | Multiple incidents consolidated into single incident; P1 priority assigned |
| 18:21 | Priority upgraded to P0 as impact severity becomes apparent |
| 18:43 | Access team explores removing Workers KV dependency through datastore migration |
| 19:09 | Gateway begins graceful degradation of rules referencing identity or device posture |
| 19:32 | Access and Device Posture force drop requests to shed load |
| 19:45 | Teams work on deploying alternative Workers KV backing datastore |
| 20:23 | Services begin recovery as storage infrastructure restores; non-negligible error rates continue |
| 20:25 | Access and Device Posture resume Workers KV calls |
| 20:28 | Service level objectives return to pre-incident levels; impact period ends |
| Later | All affected services return to normal; incident declared resolved |
Remediation and Future Steps
Cloudflare commits to several remediation efforts:
Active in-flight initiatives include accelerating work to improve Workers KV storage redundancy and eliminate dependency on any single provider. During the incident, the company began work to migrate critical KV namespaces to their own infrastructure.
Short-term remediation focuses on making individual impacted products resilient to single points of failure, including third-party dependencies.
Immediate tooling improvements aim to enable progressive namespace re-enablement during storage incidents, ensuring critical services like Access and WARP can recover without causing denial-of-service risks as caches repopulate.
The company concludes: “This was a serious outage, and we understand that organizations and institutions that are large and small depend on us to protect and/or run their websites, applications, zero trust and network infrastructure. Again we are deeply sorry for the impact and are working diligently to improve our service resiliency.”