
Výpadek Cloudflare: Databasová chyba vyřadila tisíce webů
18. listopadu 2025 postihla Cloudflare čtyřhodinová porucha způsobená změnou oprávnění v databasi. Jednoduchý přehled, co se stalo a proč.
V pondělí 18. listopadu 2025 v poledne postihla službu Cloudflare rozsáhlá porucha, která vyřadila tisíce webů a aplikací po celém světě. Výpadek trval přibližně 4 hodiny a 10 minut.
Co je Cloudflare
Cloudflare poskytuje infrastrukturu pro zrychlení a zabezpečení webů. Přes jejich síť prochází obrovské množství internetového provozu – chrání weby před DDoS útoky, zrychluje načítání stránek a poskytuje další služby.
Pokud Cloudflare vypadne, znamená to, že tisíce webů, které na něj spoléhají, se stanou nedostupnými.
Co se stalo
Výpadek začal 18. listopadu 2025 v 11:20 UTC (12:20 našeho času).
Během několika minut se staly nedostupnými desítky známých služeb:
- X (dříve Twitter)
- OpenAI / ChatGPT
- Discord
- Canva
- Figma
- 1Password
- Trello
- Medium
- Vercel
- DigitalOcean
- Spotify (částečně)
- a mnoho dalších
Uživatelé po celém světě najednou nemohli přistupovat ke svým oblíbeným službám. Na sociálních sítích se okamžitě začalo mluvit o rozsáhlém výpadku internetu.

Co způsobilo výpadek
Cloudflare vydal oficiální vysvětlení příčiny výpadku. Šlo o technickou chybu, ne o kybernetický útok.
Technický průběh
V 11:05 UTC inženýři Cloudflare provedli změnu oprávnění v databasovém systému ClickHouse. Cílem bylo vylepšit způsob, jakým fungují distribuované dotazy v databasi.
Tato změna však měla nečekaný vedlejší efekt:
- Databasový dotaz začal vracet duplicitní řádky
- Tyto duplicitní data se dostaly do souboru nazývaného „feature file“, který používá systém Bot Management
- Soubor se zdvojnásobil na velikost
- Překročil hardcodovaný limit 200 features
- To způsobilo Rust panic (pád programu) v systému, který distribuuje provoz po síti
Protože se tento soubor generoval každých 5 minut a rychle se distribuoval na všechny servery Cloudflare po celém světě, problém se během několika minut rozšířil po celé síti.
Zjednodušeně řečeno
Představte si to jako domino efekt:
- Změna v nastavení database → duplicitní data
- Duplicitní data → příliš velký konfigurační soubor
- Příliš velký soubor → překročení limitu
- Překročení limitu → pád klíčového systému
- Pád systému → nedostupnost služeb
Problém byl v tom, že tento soubor se propagoval na všechny servery v síti Cloudflare. Protože jejich hlavní proxy systém (nazývaný „Frontline“) zpracovává téměř každý požadavek, selhání se okamžitě projevilo globálně.
Co to nebylo
Důležité je zmínit, co výpadek nezpůsobilo:
- Nebyl to kybernetický útok – Cloudflare potvrdil, že nešlo o útok hackerů
- Nebyl to DDoS útok – i když se zpočátku spekulovalo o „nárůstu provozu“
- Nebyl to BGP problém – předchozí větší výpadky Cloudflare byly způsobeny chybou v BGP routingu, tentokrát šlo o jinou příčinu („Border Gateway Protocol“ je směrovací protokol, kterým si jednotlivé sítě na internetu oznamují, kudy se má provoz směrovat)
Jak to vyřešili
Cloudflare identifikoval problém a:
- Vrátil změnu v databasových oprávněních
- Zastavil generování chybných konfiguračních souborů
- Distribuoval správnou versi souboru na všechny servery
- Postupně obnovoval služby
Celý výpadek trval přibližně 4 hodiny a 10 minut. Postupné obnovování služeb trvalo další desítky minut, protože opravené soubory se musely distribuovat po celé globální síti.
Co se z toho můžeme naučit
Risiko centralisace
Výpadek ukázal, jak křehký může být internet, když velká část infrastruktury závisí na jedné společnosti.
Cloudflare je obrovská služba, ale když vypadne, ovlivní to tisíce dalších služeb najednou. Je to tzv. „single point of failure“ (jediný bod selhání).
Hardcodované limity
Problém částečně vznikl kvůli hardcodovanému limitu 200 features v systému. Když byl překročen, místo řádného ošetření chyby došlo k pádu programu.
V kritických systémech by měly být limity:
- Dobře zdokumentované
- Monitorované
- S včasným varováním před dosažením
- S řádným ošetřením chyb místo pádu
Testování změn
Změna v databasových oprávněních vypadala jako rutinní úprava, ale měla nečekané důsledky. To ukazuje důležitost:
- Postupného nasazování (rolling deployment) – změny nejdřív na části systému
- Důkladného testování – i zdánlivě malých změn
- Monitoringu – rychlá detekce anomálií
- Možnosti rychlého rollbacku – vrácení změn při problémech
Reakce Cloudflare
Matthew Prince, CEO Cloudflare, se veřejně omluvil a společnost zveřejnila podrobnou post-mortem analýzu.
Cloudflare přislíbil:
- Lepší testování změn v databasových systémech
- Zlepšení mechanismů pro detekci a prevenci podobných problémů
- Revisi hardcodovaných limitů v kritických systémech
- Lepší postupy pro rollout změn
Otevřenost a rychlost, s jakou Cloudflare přiznal chybu a zveřejnil detaily, je příkladná. Mnoho společností by podobný incident utajovalo nebo minimalisovalo.
Závěr
Výpadek Cloudflare 18. listopadu 2025 byl připomínkou, že:
- I malé změny mohou mít velké důsledky v komplexních systémech
- Centralisace internetové infrastruktury přináší risika
- Důležité je mít dobré postupy pro testování a nasazování změn
- Hardcodované limity v kritických systémech vyžadují zvláštní pozornost
- Transparentnost při řešení problémů buduje důvěru
Pro běžné uživatele to znamená: i ty nejspolehlivější služby mohou občas vypadnout. Proto je dobré mít zálohy a alternativní řešení pro kritické úkoly.
Pro vývojáře, co na Cloudflare spoléhají a provozují tam svoje weby a aplikace, je to relativně příjemné. Nemusí a často ani nemohou nic řešit, když stejně nefunguje půlka internetu.