Il 18 novembre 2025 Cloudflare ha subito quello che si è rivelato essere il peggior outage globale dal 2019. Per oltre tre ore, ampie porzioni di Internet – inclusi siti di e-commerce, strumenti SaaS e persino alcune banche – hanno rallentato drasticamente o hanno smesso del tutto di funzionare. Se la tua azienda dipende da Cloudflare per DNS, CDN o sicurezza, probabilmente hai visto clienti aggiornare le pagine di continuo o contattare il tuo team chiedendo cosa stesse succedendo.
Sui social molti utenti sono saltati subito alla conclusione più comune di questi tempi: “hack!”. Ma il CEO di Cloudflare, Matthew Prince, ha chiarito rapidamente che non si è trattato di un cyberattacco, di ransomware né dell’azione di un nation-state actor. La causa reale? Una semplice modifica interna ai permessi che ha avuto un effetto a catena del tutto imprevisto.
Se Non Sono Stati Gli Hacker, Cosa È Successo Davvero?
Quella piccola modifica ai permessi ha fatto crescere in modo anomalo un file di feature flag, che è stato distribuito sull’intera global edge fleet di Cloudflare prima che qualcuno si rendesse conto del problema. Il software non è riuscito a gestire il carico extra, innescando una serie di guasti a cascata. I sistemi si sono bloccati e i clienti di tutto il mondo ne hanno subito le conseguenze.
Gli ingegneri sono riusciti a ripristinare i servizi nel giro di poche ore. Ma per le aziende che fissavano dashboard vuote, il tempo è sembrato infinito. La lezione che imprenditori e responsabili IT, già schiacciati da sfide di leadership tecnologica e responsabilità strategiche da CIO, non possono ignorare è semplice: anche una configurazione sbagliata apparentemente minima può far inciampare un’infrastruttura solidissima.
La Leadership IT Fatica A Stare Al Passo Con La Complessità Crescente
I disservizi capitano, ma questo è arrivato in un momento in cui le aspettative tecnologiche a livello executive sono altissime, soprattutto per quanto riguarda l’adozione dell’AI e il suo impatto sulle risorse di rete. I board spingono forte sugli strumenti di AI, i team cercano di costruire cose nuove e brillanti, mentre allo stesso tempo devono “tenere accese le luci”. Il risultato è una diffusa enterprise AI fatigue: si rincorre la prossima integrazione con un LLM, mentre la gestione delle configurazioni legacy resta un rischio enorme.
L’outage di Cloudflare è un promemoria chiaro: anche sistemi che non hanno nulla a che fare con l’AI possono mandare in crash l’intera operatività. Vale la pena chiederselo seriamente: cosa si romperebbe se il tuo team commettesse un errore simile? Se la risposta è “tutto”, allora c’è un problema di architettura. E quando qualcosa va storto, ai clienti non interessa se la causa è un attacco o un errore di configurazione: vedono solo una pagina che carica all’infinito e un pulsante di checkout che non funziona.
Se non altro, questo incidente dovrebbe spingerti a controllare le tue protezioni di failover. Quando è stata l’ultima volta che le hai testate davvero? Stai semplicemente dando per scontato che entreranno in funzione quando servirà? Il famoso “99,99%” vale poco se l’unico punto che ti protegge è proprio quello che fallisce.
Le Aziende Sono Tornate Online In Fretta (Questa Volta)
L’incidente Cloudflare dimostra che correggere un errore di configurazione è molto più semplice che gestire una violazione di sicurezza. Le operazioni normali sono riprese in poco più di tre ore, con un recupero completo qualche ora dopo, perché gli ingegneri sapevano esattamente cosa si era rotto.
L’interruzione è stata una sana doccia fredda: dettagli minuscoli possono ancora buttare giù tutto. Trascurare le basi si paga caro, e la prossima volta che qualcosa andrà storto potrebbe avere un impatto ancora più grande.
