Cloudflare's grote storing op 18 november - Een samenvatting

Op 18 november 2025 viel een groot deel van het internet om.
Als je ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase of talloze kleinere sites opende, werd je begroet met een Cloudflare-gemerkte 5xx foutpagina of de sites laadden gewoon helemaal niet. Wat eerst leek op weer een groot "het internet is kapot"-moment, bleek iets subtielers te zijn en in sommige opzichten zorgwekkender: een zelf veroorzaakte bug diep in Cloudflare's eigen infrastructuur.

Hieronder volgt een gedetailleerd overzicht van wat er is gebeurd tijdens de Cloudflare storing van gisteren (18 november 2025), waarom het gebeurde, wie er last van had en welke lessen infrastructuurteams hieruit moeten trekken.

Wat gebeurde er gisteren eigenlijk?

Op dinsdag 18 november 2025, rond de late ochtend UTC, begon Cloudflare grote hoeveelheden HTTP 5xx serverfouten terug te sturen voor verkeer dat door het netwerk ging. Voor eindgebruikers betekende dit "Internal Server Error" of "Gateway Error" pagina's wanneer ze toegang probeerden te krijgen tot veel populaire websites en apps.

Volgens Cloudflare's eigen blog na het incident, was de storing:

• Begon impact te hebben op HTTP-verkeer van klanten om 11:28 UTC

• Wijdverspreide 5xx-fouten bij de kern-CDN- en beveiligingsservices

• Rond 13:05-14:30 UTC werden grote stappen genomen om de storing te beperken.

• Terugkeer van 5xx foutvolume naar basislijn tegen 17:06 UTC De Cloudflare Blog

Cloudflare zelf beschreef het als haar ergste storing sinds 2019, omdat het niet alleen van invloed was op één functie of dashboard - het verstoorde de kern van de proxylaag die het grootste deel van het klantenverkeer door haar netwerk routeert. De blog van Cloudflare

Monitoring door derden bevestigde dit. Cisco ThousandEyes zag een wereldwijde storing die Cloudflare trof, met time-outs en 5xx-fouten op services zoals X, OpenAI (ChatGPT) en Anthropic, terwijl de netwerkpaden er zelf gezond uitzagen. Dat wees sterk op een storing in de backend service, niet op ISP-niveau of een routeringsprobleem. ThousandEyes

Wie werd er getroffen?

Omdat Cloudflare voor een enorm deel van het internet zit (ongeveer 20% van de websites vertrouwen op Cloudflare voor prestaties en beveiliging), was de straal enorm. AP Nieuws+1

Onder de services die als getroffen zijn gemeld:

• ChatGPT / OpenAI

• X (voorheen Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends en andere spelplatforms

• Verschillende openbare vervoers- en overheidssites, waaronder New Jersey Transit en de digitale systemen van de Franse spoorwegen SNCF AP News+1

Storingsmonitors zoals Downdetector registreerden op het hoogtepunt duizenden gelijktijdige probleemmeldingen. Reuters rapporteerde op een gegeven moment ongeveer 5.000 getroffen gebruikers voor X alleen, voordat de tellingen afnamen naarmate de problemen werden opgelost. Reuters

Vanuit het oogpunt van de gebruiker uitte dit zich als:

• Sites die helemaal niet laden

• Aanmeldingsflows die ophingen of mislukten (vooral als Cloudflare Access of Turnstile erbij betrokken waren)

• API's reageren met tussenpozen of met 5xx-fouten

• Dashboards en beheerpanelen die uitvielen

Met andere woorden: grote delen van het internet "voelden zich down", ook al was de hoofdoorzaak geconcentreerd in de interne systemen van één provider.

Hoe Cloudflare normaal gesproken werkt (in eenvoudige bewoordingen)

Om te begrijpen waarom deze storing zo ernstig was, helpt het om het ruwe pad van een verzoek door het netwerk van Cloudflare te kennen.

Cloudflare fungeert als een reverse proxy CDN en beveiligingslaag:

1. Uw browser of app maakt verbinding met Cloudflare in plaats van rechtstreeks met de oorspronkelijke site.

2. Cloudflare beëindigt TLS en HTTP aan haar rand.

3. Verzoeken stromen in Cloudflare's core proxy systeem, genaamd FL ("Frontline") en de nieuwere generatie FL2.

4. Die kernproxy:

   • Past WAF-regels (web application firewall) toe

   • Draait botbeheermodellen

   • Verzorgt DDoS-bescherming, caching, egress to origin

   • Routeert verkeer naar andere interne producten zoals Workers, R2, Access, enz. De blog van Cloudflare

In normaal bedrijf is deze architectuur zeer veerkrachtig: als een datacenter een probleem heeft, wordt het verkeer omgeleid via andere datacenters; configuratiewijzigingen worden zorgvuldig uitgerold; individuele functies moeten op een beheerste manier uitvallen.

De storing van gisteren was juist zo erg omdat de storing zich in het gemeenschappelijke proxy-pad zelf bevond en nauw gekoppeld was aan een configuratiebestand dat regelmatig en automatisch wereldwijd wordt gepushed.

De hoofdoorzaak: een losgeslagen bestand met bot-beheerfuncties

De officiële verklaring van Cloudflare wijst naar één hoofdschuldige:
een functieconfiguratiebestand dat wordt gebruikt door hun Bot Management-systeem. De blog van Cloudflare

Hier is de keten van gebeurtenissen in gewone taal:

1. Bot Management gebruikt een "functiebestand

   • Cloudflare's bot-detectiemodel vertrouwt op een set "features" - signalen over elk verzoek die worden gebruikt om te beslissen of het een menselijke of een bot is.

   • Deze kenmerken zijn gebundeld in een configuratiebestand dat elke paar minuten opnieuw wordt gegenereerd en wereldwijd wordt uitgerold, zodat Cloudflare zich snel kan aanpassen aan nieuwe aanvalspatronen. De blog van Cloudflare

2. Een verandering in ClickHouse query gedrag

   • Het functiebestand wordt gegenereerd door query's tegen een ClickHouse-database.

   • Cloudflare heeft rond 11:05 UTC een wijziging aangebracht om de beveiliging en machtigingen voor gedistribueerde query's te verbeteren - waardoor gebruikers niet alleen metadata van een standaardschema kunnen zien, maar ook van onderliggende r0-tabellen. De blog van Cloudflare

   • De query die de lijst met kenmerken opbouwt, filterde niet op databasenaam; plotseling kreeg het dubbele kolommen van zowel standaard als r0, waardoor het aantal rijen met kenmerken verdubbelde.

3. Het bestand met eigenschappen explodeerde in grootte

   • De Bot Management module heeft een harde limiet op het aantal features dat het accepteert (ingesteld op 200, ruim boven de ~60 die normaal in gebruik zijn).

   • Toen het nieuw gegenereerde bestand die limiet overschreed, raakte de module in paniek door een onbehandelde fout in Rust code die Result::unwrap() gebruikte op een foutwaarde. De blog van Cloudflare

4. Core proxy services begonnen 5xx fouten terug te geven

   • Omdat Bot Management is geïntegreerd in het core proxy-pad, verscheen de paniek als HTTP 5xx-antwoorden voor al het verkeer dat afhankelijk was van die module.

   • Op de nieuwe FL2-engine zagen klanten expliciete 5xx-fouten.

   • Op de oudere FL-engine gingen botscores stilletjes naar nul, wat valse positieven kon veroorzaken in bot-blokkeerregels. De blog van Cloudflare

5. Het echt vervelende deel: het bestand bleef wisselen tussen "goed" en "slecht

   • Het ClickHouse cluster werd geleidelijk geüpdatet en het functiebestand werd elke vijf minuten opnieuw gegenereerd.

   • Soms liep de query op bijgewerkte knooppunten (wat een slecht bestand opleverde), soms op niet-bijgewerkte knooppunten (wat een goed bestand opleverde).

   • Dat betekende dat het netwerk van Cloudflare een tijdje schommelde tussen normale werking en storing terwijl verschillende versies van het bestand werden verspreid. De blog van Cloudflare

Deze schommeling maakte de situatie intern erg verwarrend. Aanvankelijk vermoedden de teams van Cloudflare een massale DDoS-aanval omdat het foutpatroon niet leek op een eenvoudige softwarecrash. Zelfs de Cloudflare statuspagina, die buiten hun eigen infrastructuur wordt gehost, vertoonde kortstondig fouten - een toeval dat het vermoeden van een externe aanval verder aanwakkerde. De Blog+1van Cloudflare

Pas toen ze zich realiseerden dat de gemeenschappelijke factor het bestand met botkenmerken was, werd het plaatje duidelijk.

Tijdlijn van het incident

Op basis van Cloudflare's autopsie en rapporten van derden kunnen we een ruwe tijdlijn samenstellen voor 18 november 2025: De Cloudflare Blog+2ThousandEyes+2

• 11:05 UTC - Een wijziging in de toegangscontrole van een database wordt doorgevoerd in ClickHouse.

• 11:20-11:30 UTC - Slechte versies van het Bot Management functiebestand worden gegenereerd en verspreid.

• 11:28 UTC - Eerste impact op klanten: verhoogde HTTP 5xx-fouten gezien op klantenverkeer.

• 11:30-11:32 UTC - Externe monitoringtools en geautomatiseerde tests beginnen intermitterende storingen te detecteren.

• 11:35 UTC - Cloudflare opent een interne incident call; onderzoek begint.

• ~11:48 UTC - Cloudflare publiceert een statusupdate die een incident bevestigt. Stuur opnieuw op.

• 11:30-13:05 UTC - Teams richten zich op wat verminderd KV-gedrag lijkt te zijn en onderzoeken meerdere mogelijke oorzaken (inclusief aanvalsscenario's).

• 13:05 UTC - Belangrijkste beperking: Workers KV en Cloudflare Access worden verschoven om de core proxy te omzeilen; de impact wordt verminderd. De blog van Cloudflare

• 14:30 UTC - Hoofdoorzaak geïdentificeerd; generatie en verspreiding van slechte functiebestanden is gestopt. Een bekend goed configuratiebestand wordt handmatig ingevoegd en de core proxy wordt opnieuw opgestart. Het meeste core verkeer keert terug naar normaal. De blog van Cloudflare

• 14:40-15:30 UTC - Dashboard- en aanmeldproblemen blijven bestaan doordat Turnstile en een achterstand in authenticatiepogingen secundaire belastingspieken creëren. De blog van Cloudflare

• 17:06 UTC - Foutpercentages keren terug naar basislijn; Cloudflare verklaart dat systemen volledig normaal zijn. De blog van Cloudflare

Vanuit het oogpunt van de gebruiker voelde de storing het ergst aan het einde van de ochtend tot het begin van de middag UTC, hoewel de exacte impact varieerde per regio en van welke Cloudflare-producten elke service afhankelijk was.

Waarom deze storing zo belangrijk is

Centralisatierisico

Cloudflare maakt deel uit van een kleine groep centrale aanbieders van internetinfrastructuur, naast de grote cloudplatforms (AWS, Azure, GCP) en andere grote CDN's. Wanneer één van deze spelers uitvalt, is het risico van de uitval groot. Wanneer een van deze spelers uitvalt, is de impact groot en vaak niet voor de hand liggend.

Deze storing:

• Kwam niet door een BGP-routeringsfout of een ISP-kabelbreuk.

• Kwam niet door een kwaadaardige aanval (ondanks aanvankelijke vermoedens).

• Kwam door een enkele configuratie en een bug in een intern onderdeel.

Dat is belangrijk omdat het laat zien hoe complexe, nauw gekoppelde systemen catastrofaal kunnen falen, zelfs zonder externe inmenging. Wanneer veel organisaties op dezelfde provider bouwen, wordt die provider de facto een systeemrelevant onderdeel van het internet.

"Zachte" afhankelijkheden doen ook pijn

Sommige van de getroffen services gebruikten Cloudflare niet alleen als een dom CDN. Dat waren ze ook:

• Cloudflare Access gebruiken voor authenticatie en zero-trust toegang.

• Workers KV gebruiken als onderdeel van interne controlevlakken.

• Vertrouwen op Turnstile voor bot-resistente logins. De Blog+1van Cloudflare

Toen deze producten uitvielen, was het niet alleen de inhoud van de website die uitviel - logins, beheerfuncties en interne API's gingen ook kapot. Dat maakt het herstel complexer: uw statuspagina, incidenttooling of beheerdersinterface kunnen ook afhankelijk zijn van de provider die zojuist is uitgevallen.

Wat Cloudflare zegt te zullen veranderen

De blog van Cloudflare beschrijft verschillende herstelstappen die het bedrijf al neemt om het risico te verkleinen dat iets dergelijks zich nog eens voordoet: De Cloudflare Blog

1. Verstevig de opname van automatisch gegenereerde configuratiebestanden
   Behandel intern gegenereerde configuraties met dezelfde scepsis en validatie als door de gebruiker aangeleverde input, inclusief strikte schema- en groottecontroles voordat ze worden uitgerold.

2. Meer globale uitschakelopties
   Maak het eenvoudiger om snel problematische interne modules (zoals Bot Management) over het hele netwerk uit te schakelen, zodat ze open falen in plaats van het hele proxypad in paniek te brengen.

3. Bescherm systeembronnen tegen error storms
   Zorg ervoor dat core dumps, debug metadata en observability tooling de CPU en het geheugen niet kunnen overweldigen wanneer fouten beginnen op te lopen.

4. Faalwijzen van proxy-kernmodules controleren
   Controleer systematisch hoe elke interne module zich gedraagt bij onverwachte invoer of configuratie en zorg voor een gracieuze degradatie in plaats van een globale storing.

5. Uitrol en isolatie verfijnen
   Hoewel het incident niet tot in detail is uitgewerkt, suggereert het dat Cloudflare waarschijnlijk verder zal segmenteren hoe nieuwe configuraties en DB-gedrag zich verspreiden, om de kans te verkleinen dat een enkele slechte verandering de hele vloot beïnvloedt.

Ze framen het incident ook als een absolute mislukking van hun veerkrachtverwachtingen, noemen het "onaanvaardbaar" en erkennen expliciet de pijn die het heeft veroorzaakt bij zowel klanten als gewone internetgebruikers. De blog van Cloudflare

Lessen voor infrastructuur- en SRE-teams

Zelfs als je niet zoiets groots als Cloudflare runt, zijn er een aantal zeer praktische ontwerp- en operationele lessen in deze storing:

Behandel interne config als niet-vertrouwde invoer

Het is makkelijk om aan te nemen dat "onze eigen" gegenereerde configuratie altijd correct is. Gisteren is gebleken waarom dat gevaarlijk is:

• Valideer altijd de grootte, vorm en limieten van configuratiebestanden voordat je ze toepast.

• Overweeg om de configuratie eerst toe te passen op een kleine subset van verkeer of knooppunten, met geautomatiseerde rollback bij afwijkingen.

• Houd strikte bovengrenzen en stroomonderbrekers aan rond het aantal functies, vooraf toegewezen geheugen en CPU-gebruik.

Ontwerp voor sierlijk gedeeltelijk falen

Eén bug in de Bot Management module zou niet het hele proxy pad in paniek moeten kunnen brengen:

• Standaard op fail-open vs fail-closed in sommige lagen van beveiliging als het alternatief volledige uitval is.

• Bouw duidelijke, geteste uitschakelingen voor niet-kernfuncties.

• Zorg ervoor dat kritieke subsystemen (auth, statuspagina, incidenttooling) kunnen werken in gedegradeerde modus of via alternatieve routes.

Let op de juiste signalen

De schommeling tussen "good config" en "bad config" om de vijf minuten deed het signaal lijken op aanvalsverkeer of luidruchtig extern gedrag:

• Zorg ervoor dat je per-versie of per-config correlatie hebt in je observability pipeline.

• Maak dashboards die configuratieveranderingen visueel duidelijk maken bovenop foutgrafieken.

• Zorg voor sterke synthetische tests vanuit een extern gezichtspunt, zodat je snel onderscheid kunt maken tussen interne fouten en netwerk-/pathproblemen.

Leg niet alle eieren in één inframandje

Voor organisaties die Cloudflare gebruiken:

• Overweeg multi-CDN setups voor echt bedrijfskritische eigenschappen.

• Vermijd om uw statuspagina volledig afhankelijk te maken van dezelfde provider als uw primaire stack (Cloudflare doet dit, maar er waren gisteren toevallig problemen met de host van hun statuspagina waardoor de zaken nog meer in de war raakten). De Blog+1van Cloudflare

• Denk twee keer na voordat je je authenticatie, API-controlevlakken en frontend-levering strak koppelt aan dezelfde leverancier zonder terugvalpaden.

Het grotere plaatje

Alleen al in de afgelopen maanden hebben we grote uitvallen gezien bij Microsoft Azure, Amazon Web Services en nu Cloudflare, die allemaal grote stukken van consumenten- en bedrijfsdiensten tijdelijk offline hebben gehaald. AP News+2DeWashington Post+2

Het patroon is duidelijk:

• Het internet wordt steeds afhankelijker van een handvol gigantische infrastructuuraanbieders.

• Storingen worden vaak zelf veroorzaakt door complexe interne veranderingen in plaats van aanvallen van buitenaf.

• Zelfs providers met SRE-praktijken van wereldklasse kunnen nog steeds vastlopen door onverwachte interacties tussen configuratie, databasegedrag en hardgecodeerde limieten.

Het Cloudflare-incident van gisteren herinnert ons er duidelijk aan dat "de cloud" geen magie is. Aan de basis is het nog steeds software geschreven door mensen, onderhevig aan dezelfde klassen van bugs als elke andere applicatie, alleen met ordes van grootte meer mensen die ervan afhankelijk zijn.

Voor gebruikers zal het incident vooral herinnerd worden als "die ochtend dat X en ChatGPT niet wilden laden".
Voor engineers zal het waarschijnlijk bestudeerd worden als een schoolvoorbeeld van hoe subtiele configuratie bugs in een gedistribueerd systeem kunnen uitgroeien tot een wereldwijde internet gebeurtenis.