Cloudflare's Self-Inflicted Outage Exposed the Internet's Single Point of Failure

At 6:20 AM ET on November 18, 2025, large portions of the internet simply stopped responding. There was no warning period — services that were working normally began throwing 500 errors within moments. Posts on X failed to send mid-draft, ChatGPT sessions cut out mid-reply, and Claude stalled. Even Downdetector, the tool people normally turn to for confirming an outage, was itself unreachable.

The cause traced back to Cloudflare — a company whose business is defending roughly a fifth of the web's traffic from attackers — disabling large swaths of that traffic itself. A routine database permissions change exposed a dormant bug in Cloudflare's bot-mitigation system, and the infrastructure meant to keep sites safe ended up locking them out instead.

The reaction stood in contrast to how crypto commentators had responded to a similar episode a month earlier, when an AWS failure took down Coinbase and triggered a wave of jokes about over-centralization. This time, the jokes were largely absent, at least in the first hours — mostly because the platform people use to make them, X, was among the casualties.

Several transit and logistics sites went offline, some corporate portals malfunctioned, and crypto-facing tools such as Arbiscan and DeFiLlama returned server errors — even as the underlying blockchains themselves kept producing blocks without any sign of consensus trouble.

01Timeline of the outage

According to Cloudflare's own incident writeup, the sequence began at 11:05 UTC, when engineers pushed an access-control change to a database cluster. By 11:28 UTC, that change had propagated to production and the first customer-facing HTTP errors appeared. Twenty minutes later, at 11:48 UTC, Cloudflare's status page acknowledged "internal service degradation" — a mild phrase for what was, in practice, a network-wide failure.

The change had broken Cloudflare's bot-management layer: its proxy service choked after loading a configuration file that had suddenly doubled in size. Downstream, Workers KV and Access lost their connection to the proxy, error rates spiked, and CPU usage climbed as monitoring systems strained under the load. Requests kept arriving at Cloudflare's edge network, but the proxy had no way to answer them.

For a time, Cloudflare's own engineers believed they were the target of a large-scale DDoS attack. That suspicion deepened when the status page — hosted entirely on separate infrastructure — also went dark at the same moment, suggesting a coordinated strike on both the network and its monitoring. In reality, nothing external was attacking Cloudflare; the company had broken itself.

CTO Dane Knecht issued a public apology once service was restored, describing the episode as "unacceptable" and tracing it to a routine configuration change that crashed the bot-mitigation layer:

"We failed our customers and the broader internet. A latent bug in a service underpinning our bot mitigation capability started to crash after a routine configuration change. That cascaded into a broad degradation to our network and other services. This was not an attack."

Downdetector logged 11,183 reports at the peak of the incident. Full restoration wasn't declared until 17:06 UTC — more than five and a half hours after the first errors — though the sharpest impact had subsided by roughly 14:30 UTC, once a corrected Bot Management configuration file finished rolling out globally.

02Who got hit

Mainstream web services absorbed the first wave of damage. X recorded 9,706 outage reports, with users seeing generic "Oops, something went wrong" messages in place of their timelines. ChatGPT conversations cut off mid-response. Spotify stopped streaming, Canva locked users out, and both Uber and DoorDash reported disruptions. Gamers weren't spared either — League of Legends players were disconnected mid-match — and some users reported McDonald's self-service kiosks displaying error screens.

Crypto-facing platforms fared no better. Coinbase's website went unreachable, leaving users stuck on broken login screens. Both Kraken's web and mobile apps failed as a direct consequence of Cloudflare's collapse. BitMEX posted a status update confirming it was investigating degraded performance while stressing that user funds remained safe — the same reassurance other exchanges would repeat. Etherscan stopped loading, and Arbiscan went down alongside it. DeFiLlama's dashboard intermittently returned internal server errors, and Ledger reported degraded availability of some services tied directly to the Cloudflare incident.

Not every exchange was affected. Binance, OKX, Bybit, Crypto.com, and KuCoin reportedly saw no front-end outages, and on-chain activity continued uninterrupted throughout. Crucially, the blockchains underlying all of this kept operating normally — the failure sat entirely in the Web2 layer people use to reach them, not in the protocols themselves.

03What actually broke

Cloudflare doesn't host websites or run cloud servers the way AWS does. It sits in front of an estimated 24 million domains, routing roughly 20% of all web traffic through data centers in 330 cities across 120 countries. Its pitch is a combined shield and accelerator: DDoS protection, bot mitigation, a global web application firewall, TLS termination, DNS, and edge compute through Workers, all on one network. In practice, that translates to an 82% share of the DDoS-protection market and 449 Tbps of edge capacity, interconnected with most of the world's major ISPs and cloud providers. The tradeoff of sitting in the middle of so much traffic is that when the middleman fails, everything behind it becomes unreachable at once.

CEO Matthew Prince called it, in his own words, "Cloudflare's worst outage since 2019," adding that in over six years the company hadn't seen an incident that stopped the majority of its core traffic from flowing. Knecht was similarly direct on X: "I won't mince words: earlier today we failed our customers and the broader Internet when a problem in Cloudflare network impacted large amounts of traffic that rely on us."

The technical root cause, per Cloudflare's post-incident report, started with the 11:05 UTC change to a ClickHouse database cluster, intended to make table metadata explicitly visible to users who already had implicit access to it — a security and reliability improvement. The unintended consequence was that a query responsible for generating the configuration file for Cloudflare's bot-mitigation service stopped filtering results by database name. That query began pulling duplicate rows: one set from the default database, a second set from the underlying r0 storage layer. The resulting feature file ballooned from roughly 60 entries to more than 200.

Cloudflare had built in a hardcoded ceiling of 200 features for memory preallocation, a limit the company had described as "well above our current use of ~60 features." The oversized file exceeded that ceiling, and the Rust service handling it panicked with the error: thread fl2_worker_thread panicked: called Result::unwrap() on an Err value.

Because bot mitigation sits deep in Cloudflare's control plane, its failure disrupted the health-check system load balancers rely on to know which servers are functioning. Making matters more confusing, the bad configuration file regenerated every five minutes, but corrupted data only appeared when the underlying query ran against an already-updated cluster node. That meant the network alternated between good and bad files every five minutes, flipping between working and failing — a pattern that looked far more like an external DDoS attack than an internal software bug, since systems don't typically recover and fail repeatedly on their own. Eventually every ClickHouse node was updated, every generated file was bad, and the flickering stopped in favor of a stable, complete failure. With no reliable health signals, the system defaulted to treating most servers as unhealthy; requests kept arriving at the edge but couldn't be routed to anything.

Knecht reiterated that the incident had nothing to do with malicious activity: "This was not an attack." It was a missing filter in a database query colliding with an unrelated permissions update at the wrong moment. Cloudflare's marketed "99.99% uptime guarantee" did not hold for this event.

04A pattern of infrastructure failures

The Cloudflare incident joins a string of similar events over the past year and a half:

• October 20, 2025 — AWS suffered a 15-hour outage after DynamoDB DNS resolution failed in the US-EAST-1 region. Coinbase froze, Robinhood stuttered, and Infura's disruption knocked out MetaMask. Base, Polygon, Optimism, Arbitrum, Linea, and Scroll all went offline at the front end, showing users zero balances despite funds remaining untouched on-chain.
• October 29, 2025 — A configuration-propagation problem in Microsoft Azure's Front Door service took down Microsoft 365, Xbox Live, and various business tools.
• July 2024 — A faulty CrowdStrike Windows update grounded flights, delayed hospital procedures, and froze financial services for days.
• June 2022 — An earlier Cloudflare outage halted several crypto exchanges.
• July 2019 — An even earlier Cloudflare failure took Coinbase and CoinMarketCap offline.

Four major infrastructure failures inside eighteen months, each pointing to the same underlying issue: concentrating infrastructure in a handful of providers concentrates the blast radius when something goes wrong.

05The gap between decentralized branding and centralized reality

Crypto's founding pitch has always emphasized censorship resistance, trustless execution, and the absence of any single point of failure. November 18 tested that pitch against reality. The technical result was reassuring on one level — no blockchain protocol reported any failure; Bitcoin and Ethereum both kept producing blocks normally. The practical result was less reassuring: exchange interfaces went dark, block explorers stopped loading, wallet front ends failed, analytics dashboards crashed, and trading interfaces returned server errors. Users could not reach the "decentralized" systems they nominally controlled, even though the protocols underneath were functioning exactly as designed.

Industry figures were blunt about what that gap meant. David Schwed, COO of SovereignAI, put it plainly:

"With Cloudflare down today and AWS just a few weeks ago, it's evident we can't simply outsource resiliency in our infrastructure to a single vendor. If your organization needs to be up 24/7, you have to build your infrastructure assuming these outages will happen. A business continuity plan comprised of 'wait for vendor to restore' is pure negligence."

Jameson Lopp made a similar point: "We took an amazing decentralized technology and have made it incredibly fragile by centralizing most services behind a handful of providers." And a line Ben Schiller wrote during the earlier AWS outage — "If your blockchain is down because of the AWS outage, you're not sufficiently decentralized" — applied just as well with Cloudflare substituted in.

The reasons for that dependence are mostly economic. Operating independent infrastructure means buying hardware, securing reliable power and bandwidth, hiring security staff, building geographic redundancy, and running disaster-recovery and monitoring programs around the clock. Using Cloudflare, by comparison, requires little more than a credit card and a few minutes of setup — someone else absorbs the DDoS risk, the uptime obligations, and the scaling questions. Startups optimizing for speed to market, backed by investors optimizing for capital efficiency, largely chose the easier path.

The contrast with October is telling: when AWS went down, X remained functional, and crypto commentators spent the day mocking centralized dependencies. When Cloudflare went down, X went down with it, and the joke had nowhere to be posted. Protocol-level decentralization doesn't mean much when the access layer for that protocol runs through a small number of companies — two of whom failed within the same month.

06Three companies, most of the internet

Cloud infrastructure itself is concentrated: AWS holds roughly 30% of the global market, Microsoft Azure about 20%, and Google Cloud around 13% — together, more than 60% of the infrastructure the modern internet runs on. An industry built around avoiding centralization runs, in practice, on some of the most centralized infrastructure that exists. Coinbase, Binance, BitMEX, Huobi, and Crypto.com all run on AWS, and Kraken's infrastructure sits on AWS as well — though that didn't stop it from getting caught by Cloudflare's CDN failure regardless.

With three major outages inside 30 days, the pattern hasn't gone unnoticed by regulators, raising questions about whether backbone internet providers should be treated as systemically important, whether utility-style oversight applies to companies like Cloudflare, and whether controlling a fifth of global web traffic constitutes a monopoly concern. Article 19's Corinne Cath-Speth made a related point after the AWS incident: "When a single provider goes dark, critical services go offline with it – media outlets become inaccessible, secure communication apps like Signal stop functioning, and the infrastructure that serves our digital society crumbles. We urgently need diversification in cloud computing."

Decentralized alternatives to this infrastructure already exist — Arweave for storage, IPFS for distributed file systems, Akash for compute, Filecoin for hosting — but adoption remains minimal. Performance lags centralized options, latency is noticeable, and costs frequently run higher than simply renting from one of the major providers. Building infrastructure that is genuinely decentralized is difficult and expensive, and most projects that talk about it don't actually implement it, because centralized options remain cheaper and easier — until an outage makes the tradeoff visible.

Dr. Max Li, CEO of OORT, made this point in a CoinDesk op-ed: "For an industry that prides itself on decentralization and constantly lauds its benefits, to be so reliant on vulnerable centralized cloud platforms for their own infrastructure feels like hypocrisy." His proposed fix is a hybrid model, spreading critical systems across decentralized networks rather than concentrating them with one vendor — acknowledging that centralized clouds will still have a role for raw performance and scale, but arguing they can't match the resilience of distributed systems when large sums of money and split-second timing are on the line.

07What comes next

The blockchains themselves worked exactly as intended on November 18 — the failure was entirely in the surrounding access layer. But that distinction is cold comfort if a chain can produce blocks while nobody can actually submit a transaction to it. Right now, the industry's practical disaster-recovery plan for outages like this amounts to waiting for the vendor — Cloudflare, AWS, or Azure — to fix the problem on its own timeline.

That dependency becomes more consequential as regulators push identity verification deeper into the system. Proposals to embed identity credentials in smart contracts and require KYC checks on DeFi interactions assume the underlying infrastructure will be available when needed. An outage under that regime wouldn't just block trading — it would block the verification step needed to prove someone is even allowed to trade, since that verification service would likely run on the same kind of centralized infrastructure that just failed.

Three outages in roughly a month have not been severe enough to force a change in how the industry builds. The recurring question is how many more of these events it will take before infrastructure resilience gets treated as a genuine requirement rather than an afterthought — particularly since another outage, whether from Cloudflare, AWS, Azure, or Google Cloud, is a matter of when rather than if, and the underlying incentives that produced this one haven't changed.

REKT serves as a public platform for anonymous authors, we take no responsibility for the views or content hosted on REKT.