Op 12 juni 2025 ondervond Cloudflare een ernstige storing die gevolgen had voor een groot aantal van onze kritieke services, waaronder Workers KV, WARP, Access, Gateway, Images, Stream, Workers AI, Turnstile en Challenges, AutoRAG, Zaraz en onderdelen van het Cloudflare Dashboard.
Deze storing duurde 2 uur en 28 minuten en had wereldwijd gevolgen voor alle Cloudflare-klanten die gebruikmaakten van de getroffen services. De oorzaak van deze storing was een defect van de onderliggende opslaginfrastructuur die door onze Workers KV-service wordt gebruikt. Dit is een kritieke afhankelijkheid van veel Cloudflare-producten voor de configuratie, authenticatie en levering van activa voor de getroffen services. Een deel van deze infrastructuur wordt ondersteund door een externe cloudprovider die vandaag een storing ondervond, wat een directe impact had op de beschikbaarheid van onze KV-service.
We verontschuldigen ons voor deze storing. Dit was een fout van ons, en hoewel de directe oorzaak (of trigger) voor deze uitval een storing van een externe leverancier was, zijn wij uiteindelijk verantwoordelijk voor de door ons gekozen afhankelijkheden en de manier waarop we besluiten om die te structureren.
De uitval was niet het gevolg van een aanval of een ander beveiligingsincident. Er is geen data verloren gegaan als gevolg van dit incident. Cloudflare Magic Transit en Magic WAN, DNS, cache, proxy, WAF en gerelateerde services ondervonden geen rechtstreekse impact van dit incident.
Als regel ontwerpt en bouwt Cloudflare haar services op haar eigen platformelementen. Veel producten van Cloudflare vertrouwen dan ook op de Workers KV-service.
In de volgende tabel staan de getroffen services, inclusief de impact op de gebruikers, de operationele defecten en de waargenomen toename van de foutpercentages:
Product/dienst | Impact |
|---|
Workers KV
| Bij Workers KV mislukte 90,22% van de verzoeken: elk sleutelwaardepaar dat niet in de cache was opgeslagen en elk paar dat nodig was om de waarde op te halen uit de oorspronkelijke opslag-backends van Workers KV resulteerde in mislukte verzoeken met responscode 503 of 500. De resterende verzoeken werden met succes afgehandeld vanuit de cache van Workers KV (statuscode 200 en 404) of leverden fouten op die binnen de verwachte limieten en/of het foutenbudget vielen. Dit had geen invloed op de data die in Workers KV was opgeslagen. |
Toegang
| Access maakt gebruik van Workers KV om de configuratie van de applicaties en beleidsbepalingen op te slaan, samen met de identiteitsgegevens van gebruikers. Tijdens het incident mislukte Access bij 100% van de identiteitsgebaseerde inlogpogingen voor alle soorten applicaties, waaronder zelfgehoste, SaaS- en infrastructuurapplicaties. Ook waren de identiteitsgegevens van de gebruiker niet beschikbaar voor andere services, zoals WARP of Gateway. Access sluit automatisch als de beleidsconfiguratie of de identiteit van een gebruiker niet kan worden opgehaald. De SSH-sessies van de actieve infrastructuurtoepassing waarvoor de opdrachtregistratie was ingeschakeld, konden geen logboeken opslaan vanwege de afhankelijkheid van Workers KV. De SCIM-service (System for Cross Domain Identity) van Access had ook last van de afhankelijkheid van Workers KV en Durable Objects (die afhankelijk zijn van KV) om de gebruikersinformatie op te slaan. Tijdens dit incident werd de gebruikersinformatie niet bijgewerkt vanwege de mislukte Workers KV-updates. Deze storing zorgde ervoor dat een 500-fout naar de identiteitsproviders werd teruggestuurd. Sommige providers vereisen een handmatige hersynchronisatie, maar de meeste klanten zagen direct een herstel van de service zodra de SCIM-service van Access was hersteld dankzij de herhaallogica van de identiteitsprovider. De op service-authenticatie gebaseerde logins (bijv. service token, Mutual TLS en op IP-gebaseerde beleidsregels) en het Bypass-beleid waren ongemoeid. Tijdens deze periode zijn er geen wijzigingen of aanpassingen van het Access-beleid verloren gegaan. |
Gateway
| Dit incident had geen invloed op de meeste Gateway DNS-query's, zoals query's via IPv4, IPv6, DNS over TLS (DoT) en DNS over HTTPS (DoH). Er waren echter twee uitzonderingen: De DoH-query's met identiteitsgebaseerde regels mislukten. Dit gebeurde omdat Gateway de vereiste gebruikersidentiteitsgegevens niet kon ophalen. Voor sommige gebruikers werd de geauthenticeerde DoH verstoord. Gebruikers met actieve sessies met geldige authenticatietokens hadden geen last, maar gebruikers die een nieuwe sessie wilden starten of authenticatietokens wilden vernieuwen, konden dat niet. De gebruikers van Gateway-proxy-, uitstromings- en TLS-decodering konden geen verbinding maken, konden zich niet registreren, en konden geen proxy gebruiken of verkeer registreren. Dit omdat wij afhankelijk zijn van Workers KV om actuele informatie over de identiteit en toestand van het apparaat op te halen. Voor elk van deze acties is Workers KV nodig. Als dat niet beschikbaar is, wordt Gateway automatisch gesloten om te voorkomen dat het verkeer de door de klant geconfigureerde regels omzeilt. |
WARP
| De WARP-client werd getroffen vanwege de afhankelijkheid van Access en Workers KV, die vereist zijn voor de apparaatregistratie en -authenticatie. Hierdoor konden nieuwe cliënten tijdens het incident geen verbinding maken en zich niet aanmelden. Bestaande WARP-clientgebruikerssessies die via de Gateway-proxy werden gerouteerd, ondervonden onderbrekingen, omdat Gateway de vereiste beleidsevaluaties niet kon uitvoeren. Bovendien was de override van de WARP-nooduitschakeling niet beschikbaar vanwege een storing van de onderliggende afhankelijkheid, namelijk Workers KV. Bij Consumer WARP was er sprake van dezelfde sporadische impact als bij de Zero Trust-versie. |
Dashboard
| De gebruikersaanmeldingen op het dashboard en de meeste bestaande dashboardsessies waren niet beschikbaar. Dit kwam door een storing die gevolgen had voor Turnstile, DO, KV en Access. De specifieke oorzaken voor de mislukte aanmeldingen waren: Standard logins (gebruiker/wachtwoord): mislukt omdat de Turnstile niet beschikbaar was. Aanmelden met Google (OIDC)-aanmeldingen: mislukt vanwege een KV-afhankelijkheidsprobleem. SSO-aanmeldingen: mislukt vanwege de volledige afhankelijkheid van Access. De Cloudflare v4 API had geen last van dit incident. |
Challenges en Turnstile
| Het Challenge-platform dat Cloudflare Challenges en Turnstile aanstuurt, ondervond een hoog percentage fouten en time-outs voor siteverify-API-verzoeken tijdens de incidentperiode vanwege de afhankelijkheid van Workers KV en Durable Objects. We hebben kill-switches geïnstalleerd om deze verzoeken uit te schakelen in geval van incidenten en storingen zoals deze. We hebben deze kill-switches geactiveerd als een mitigatie, zodat bezoekers niet wordt belemmerd. Opvallend is dat de siteverify-API van Turnstile (de API die uitgegeven tokens valideert) de geldige tokens meerdere keren kon inwisselen terwijl deze kill-switches actief waren. Dit zou aanvallen mogelijk hebben kunnen maken als kwaadwillenden een eerder geldige token gebruikten om de validatie te omzeilen. Er was geen impact op het vermogen van Turnstile om bots te detecteren. Een bot die een uitdaging probeerde omzeilen, zou nog steeds zijn mislukt en zou dus geen token hebben ontvangen. |
Browserisolatie
| De bestaande, op links gebaseerde Browser Isolation-sessies werden getroffen vanwege de Gateway-afhankelijkheid voor de beleidsevaluatie. Nieuwe op links gebaseerde Browser Isolation-sessies konden niet worden gestart vanwege een afhankelijkheid van Cloudflare Access. Alle door Gateway geïnitieerde isolatiesessies mislukten vanwege de Gateway-afhankelijkheid. |
Afbeeldingen
| Uploads naar Cloudflare Images werden door het incident beïnvloed, met een foutpercentage van 100% op het hoogtepunt van het incident. Het algehele succespercentage van de levering van afbeeldingen daalde tot ongeveer 97%. Image Transformations waren niet ernstig getroffen, net zomin als Polish. |
Stream
| Het foutpercentage van Stream overschreed de 90% tijdens de incidentperiode, omdat videoafspeellijsten niet konden worden verwerkt. Stream Live constateerde een foutpercentage van 100%. Het probleem had geen gevolgen voor het uploaden van video's. |
Realtime
| De Realtime TURN-service (Traversal Using Relays around NAT) maakt gebruik van KV en werd zwaar getroffen. Het foutpercentage lag tijdens de incidentperiode nagenoeg op 100%. De Realtime SFU-service (Selective Forwarding Unit) kon geen nieuwe sessies aanmaken, hoewel bestaande verbindingen gehandhaafd bleven. Hierdoor daalde het normale verkeersvolume tijdens de impactperiode met 20%. |
Workers AI
| Alle inferentieverzoeken aan Workers AI mislukten tijdens het incident. Workers AI is afhankelijk van Workers KV voor de wereldwijde distributie van configuratie- en routing-informatie voor AI-verzoeken. |
Pages en Workers Assets
| Statische assets die door Cloudflare Pages en Workers Assets worden verwerkt (zoals HTML, JavaScript, CSS, afbeeldingen, etc.) worden in Workers KV opgeslagen, gecached en op het moment van het verzoek opgehaald. Workers Assets zag in deze periode een toename van de gemiddelde foutmarge van ongeveer 0,06% van het totale aantal verzoeken. Tijdens de incidentperiode bereikte het foutpercentage van Pages een piek van circa 100% en kon geen enkele Pages-build worden afgerond. |
AutoRAG
| AutoRAG maakt gebruik van Workers AI-modellen voor zowel documentconversie als het genereren van vector-embeddings tijdens de indexering. Daarnaast maakt AutoRAG gebruik van LLM-modellen voor query's en zoekopdrachten. AutoRAG was tijdens het incidentvenster niet beschikbaar vanwege de afhankelijkheid van Workers AI. |
Duurzame objecten
| De door SQLite-ondersteunde Durable Objects delen dezelfde onderliggende opslaginfrastructuur als Workers KV. Het gemiddelde foutpercentage bereikte tijdens de incidentperiode een piek van 22% en daalde naar 2% toen de services zich begonnen te herstellen. De Durable Object-naamruimten die gebruikmaken van de oude sleutelwaardeopslag, bleven ongemoeid. |
D1
| D1-databases delen dezelfde onderliggende opslaginfrastructuur als Workers KV en Durable Objects. Net als bij Durable Objects bereikte het gemiddelde foutpercentage tijdens de incidentperiode een piek van 22%. Toen de services zich begonnen te herstellen, daalde dit percentage naar 2%. |
Queues- en gebeurtenismeldingen
| Queues-berichten, waaronder pushing en consuming, waren tijdens de incidentperiode niet beschikbaar. Queues gebruikt KV om elke Queue aan onderliggende Durable Objects toe te wijzen die wachtrijberichten bevatten. Gebeurtenismeldingen gebruiken Queues als onderliggend aflevermechanisme. |
AI Gateway
| AI Gateway is gebouwd op Workers en vertrouwt op Workers KV voor interne en client-configuraties. Tijdens de incidentperiode zag AI Gateway het foutpercentage pieken op 97% van de verzoeken totdat de afhankelijkheden waren hersteld. |
CDN
| De infrastructuur voor geautomatiseerd verkeersmanagement was operationeel, maar functioneerde tijdens de impactperiode minder effectief. Vooral het aantal registratieverzoeken van Zero Trust-klanten was door de storing fors toegenomen. Deze toename van het aantal verzoeken zorgde voor een extra belasting van verschillende Cloudflare-locaties, waardoor een reactie van het geautomatiseerde verkeersbeheer werd geactiveerd. Als reactie op deze omstandigheden leidden systemen het binnenkomende CDN-verkeer om naar locaties in de buurt, waardoor de gevolgen voor de klanten werden beperkt. Een deel van het verkeer werd echter niet omgeleid zoals verwacht, en dit wordt onderzocht. CDN-verzoeken die door dit probleem werden beïnvloed, ondervonden een verhoogde latentie, HTTP 499-fouten en/of HTTP 503-fouten. De getroffen Cloudflare-servicegebieden waren onder meer São Paulo, Philadelphia, Atlanta en Raleigh. |
Workers/Workers for Platforms
| Workers en Workers for Platforms zijn voor het uploaden afhankelijk van een externe service. Tijdens de incidentperiode zag Workers een piek van het totale foutpercentage van circa 2% van het totaal aantal verzoeken. Workers for Platforms zag in dezelfde periode een piek van het totale foutpercentage van circa 10% van het totaal aantal verzoeken. |
Workers Builds (CI/CD)
| Vanaf 18.03 uur UTC konden Workers-builds geen nieuwe push-gebeurtenissen voor broncodebeheer meer ontvangen, omdat Access niet beschikbaar was. 100% van de nieuwe Workers Builds mislukte tijdens de incidentperiode. |
Browser Rendering
| Browser Rendering is afhankelijk van Browser Isolation voor de infrastructuur van browserinstanties. Verzoeken naar zowel de REST API als via de Workers Browser Binding werden allemaal door het incident getroffen. |
Zaraz
| 100% van de verzoeken werd tijdens de incidentperiode beïnvloed. Zaraz maakt gebruik van Workers KV-configuraties voor websites bij het verwerken van bezoekersverkeer. Vanwege dezelfde afhankelijkheid mislukten de pogingen om in deze periode updates van de Zaraz-configuraties op te slaan, maar uit onze monitoring blijkt dat dit slechts één gebruiker betrof. |
Workers KV is gebouwd als een zogeheten ‘coreless’ service. Dit betekent dat er geen enkel punt van falen zou moeten zijn, omdat de service onafhankelijk op al onze locaties wereldwijd draait. Tegenwoordig is Workers KV echter afhankelijk van een centrale data-opslag om een bron van waarheid voor de data te bieden. Door een storing in die opslag ontstond er een volledige uitval van koude lees- en schrijfbewerkingen naar de KV-naamruimten die door de services van Cloudflare worden gebruikt.
Workers KV worden momenteel overgezet naar een aanzienlijk veerkrachtigere infrastructuur voor de centrale opslag. Helaas was er tijdens dit incident sprake van een leemte in deze dekking. Workers KV verwijderde een opslagprovider terwijl we bezig waren met het nieuwe ontwerp van de backend van KV, inclusief de migratie naar Cloudflare R2, om problemen met dataconsistentie te voorkomen (veroorzaakt door de oorspronkelijke architectuur voor gegevenssynchronisatie) en de ondersteuning voor de data-residentievereisten te verbeteren.
Een van onze principes is om Cloudflare-services zoveel mogelijk op ons eigen platform te bouwen, en Workers KV vormt hierop geen uitzondering. Veel van onze interne en externe services zijn sterk afhankelijk van Workers KV. Dit helpt ons normaal gesproken om de meest robuuste services te leveren, zodat serviceteams niet hun eigen opslagservices hoeven te bouwen. In dit geval heeft de cascade-impact van het falen van Workers KV het probleem verergerd en de storing veel groter gemaakt.
Tijdlijn en impact van het incident
Hieronder staat een tijdlijn van het incident, inclusief de initiële impact, het onderzoek, de grondoorzaak en de getroffen corrigerende maatregelen.
Workers KV-foutpercentages voor opslaginfrastructuur. 91% van de verzoeken aan KV mislukten tijdens de incidentperiode.
Percentage succesvolle verzoeken via Cloudflare Access. Cloudflare Access is rechtstreeks afhankelijk van Workers KV en fungeert als een goede proxy om de beschikbaarheid van Workers KV in de loop der tijd te meten.
Alle vermelde tijdstempels zijn in Coordinated Universal Time (UTC).
Tijdstip | Evenement |
|---|
2025-06-12 17.52 | START VAN HET INCIDENT
Het WARP-team van Cloudflare ziet dat de registratie van nieuwe apparaten mislukt, begint deze fouten onderzoeken en maakt melding van een incident. |
2025-06-12 18.05 | Het Cloudflare Access-team ontvangt een waarschuwing vanwege de snel toenemende foutpercentages. Service Level Objectives voor meerdere services voldoen niet aan de eisen, waardoor de desbetreffende teams worden gewaarschuwd. |
2025-06-12 18.06 | Meerdere servicespecifieke incidenten worden gecombineerd tot één incident, aangezien we een gedeelde oorzaak hadden geïdentificeerd (onbeschikbaarheid van Workers KV). De incidentprioriteit wordt verhoogd naar P1. |
2025-06-12 18.21 | De incidentprioriteit wordt van P1 verhoogd naar P0 aangezien de ernst van de impact duidelijker wordt. |
2025-06-12 18.43 | Cloudflare Access gaat samen met het Workers KV-engineeringteam op zoek naar opties om de afhankelijkheid van Workers KV te verwijderen door naar een andere back-up data-opslag te migreren. Dit was een proactieve maatregel voor het geval de opslaginfrastructuur onbeschikbaar zou blijven. |
2025-06-12 19.09 | Zero Trust Gateway is begonnen met het verwijderen van de afhankelijkheden van Workers KV door de regels die verwijzen naar de identiteit of toestand van het apparaat op een elegante manier te degraderen. |
2025-06-12 19.32 | Access en Device Posture forceren de verwijdering van verzoeken voor de identiteit en toestand van het apparaat om de werklast van Workers KV te verlagen totdat de service van derden weer online is. |
2025-06-12 19.45 | De teams van Cloudflare werken nog steeds aan de implementatie van een Workers KV-release met een alternatieve back-up data-opslag en zorgen ervoor dat essentiële services alle configuratiedata naar die opslag sturen. |
2025-06-12 20.23 | De diensten beginnen zich te herstellen, aangezien de opslaginfrastructuur zich begint te herstellen. We zien nog steeds een hoog foutenpercentage en minder infrastructuurverzoeken vanwege de toestroom van de services die de caches opnieuw vullen. |
2025-06-12 20.25 | Access en Device Posture herstellen de verzoeken aan Workers KV, aangezien de service van derden is hersteld. |
2025-06-12 20.28 | EINDE VAN DE IMPACT
Service Level Objectives keren terug naar het niveau van vóór het incident. De Cloudflare-teams blijven de systemen monitoren om er zeker van te zijn dat de services niet verslechteren terwijl de afhankelijke systemen zich herstellen. |
| EINDE VAN HET INCIDENT
Het Cloudflare-team ziet dat alle getroffen services weer normaal functioneren. Waarschuwingen met betrekking tot serviceniveaudoelstellingen worden ingetrokken. |
Corrigerende maatregelen en vervolgstappen
We treffen onmiddellijk maatregelen om de veerkracht van services die afhankelijk zijn van Workers KV en onze opslaginfrastructuur te verbeteren. Dit geldt ook voor de geplande werkzaamheden die we als gevolg van dit incident zullen versnellen.
Dit omvat verschillende werkstromen: niet alleen inspanningen om te voorkomen dat er sprake is van een unieke afhankelijkheid van een opslaginfrastructuur die we niet zelf in eigendom hebben, maar ook inspanningen om ons vermogen te verbeteren om kritieke services te herstellen (waaronder Access, Gateway en WARP).
Meer specifiek:
(Actief in uitvoering): We werken verder aan de verbetering van de redundantie binnen de opslaginfrastructuur van Workers KV, waardoor we niet langer afhankelijk zijn van één enkele provider. Tijdens de incidentperiode zijn we begonnen met het overzetten en aanvullen van kritieke KV-naamruimten naar onze eigen infrastructuur, voor het geval het incident zich zou blijven voordoen.
(Actief in uitvoering): Kortetermijnmaatregelen voor afzonderlijke producten die door dit incident zijn getroffen, zodat elk product bestand wordt tegen serviceverlies als gevolg van het falen van één punt, inclusief afhankelijkheden van derden.
(Actief in uitvoering): Implementatie van tooling waarmee we de naamruimten tijdens incidenten met de opslaginfrastructuur geleidelijk opnieuw kunnen inschakelen. Hierdoor kunnen we ervoor zorgen dat grote afhankelijkheden, waaronder Access en WARP, kunnen worden opgestart zonder het risico van een denial-of-service tegen onze eigen infrastructuur wanneer de caches opnieuw worden gevuld.
Deze lijst is niet compleet: onze teams herzien de ontwerpbeslissingen voortdurend en beoordelen welke infrastructuurwijzigingen we op de korte (directe) termijn en op de lange termijn moeten doorvoeren om incidenten zoals deze in de toekomst te voorkomen.
Dit was een ernstige storing en we begrijpen dat grote en kleine organisaties en instellingen op ons vertrouwen voor de beveiliging en/of werking van hun websites, applicaties, Zero Trust en netwerkinfrastructuur. Nogmaals, wij betreuren de impact ten zeerste en zijn hard aan het werk om de veerkracht van onze dienstverlening te verbeteren.