The claim circulating on Hacker News this week is that nearly 9 in 10 European companies using a CDN use Cloudflare. The short answer: none of the sources reviewed can verify that number, and the only independent telemetry we have, W3Techs’ roughly 21.3% of all websites as of January 2026, measures a different thing entirely. The practical consequence stands regardless of the exact figure: if your failover path resolves to the same vendor as your primary, you do not have redundancy.
Does the 9-in-10 claim hold up against independent telemetry?
No. The figure appears in a single Hacker News post and cannot be anchored to any methodology, dataset, or primary source in the sources reviewed. That does not make it wrong; it makes it unusable as a planning input until someone publishes the denominator.
The lifecycle of an unanchored number is predictable. It appears in a comment, gets repeated without its caveat, acquires a “widely reported” provenance within a day, and is eventually cited back as common knowledge. The correction, when it arrives, carries a denominator and reaches a tenth of the audience. If the figure is going to circulate internally, attach its provenance to it: one HN post, observed 2026-09-08, no methodology, no fetched source.
The denominator question is where market-share statistics go to die. “Nearly 9 in 10 European companies that use a CDN” implies a survey or measurement of European companies, filtered to CDN users, with a vendor breakdown. None of the sources reviewed contains such a measurement. What we have instead are three numbers that sound adjacent and measure three different populations:
| Claim | Source | Denominator | Evidence quality |
|---|---|---|---|
| ~9 in 10 European CDN users run Cloudflare | HN post, observed 2026-09-08 | European companies using a CDN (methodology unstated) | Single-source, no fetched URL, unverified |
| ~21.3% of all websites (January 2026) | W3Techs, via Wikipedia | All websites globally | Independent telemetry, different population |
| 45% of the Fortune 500 | Cloudflare homepage | Fortune 500 companies | Vendor self-report |
The honest reading: 21.3% of all websites is a long way from the 9 in 10 share claimed for European CDN users, but the two are not directly comparable. Cloudflare’s share among sites that use a CDN at all is much higher than its share of all sites, because a large fraction of the web runs no CDN or runs one bundled with hosting. European enterprise skew could plausibly push the conditional share higher still. Plausible is not measured. Treat the headline as a hypothesis, not a fact.
What verification would look like is not mysterious. A defensible version of the claim needs either a survey of European companies with a published sampling frame, or passive measurement: resolve a representative sample of European domains from European vantage points, classify the serving network, and report the denominator. W3Techs runs something close to the second method globally, at the website level; a regional cut of the same methodology would settle the argument in an afternoon. It has not been published. Until it is, the claim functions as motivation for an audit, not as an input to one.
How big is Cloudflare’s network, really?
Big enough that the concentration question is legitimate even if the 9-in-10 figure is not. Cloudflare’s own homepage states that its security, connectivity, and code run in more than 335 cities, within 50 milliseconds of 95% of the world’s population, and that it powers 45% of the Fortune 500. These are vendor marketing numbers and should be read as such, but the independent figure points the same direction: 21.3% of all websites, per W3Techs, means roughly one site in five on the Internet fronting its traffic through a single vendor.
Scale is the lock-in driver, and it compounds through features rather than contracts. Cloudflare is not merely a CDN; it bundles DDoS mitigation, cloud cybersecurity, ICANN-accredited domain registration, DNS, and a compute edge into one control plane. Each additional service a team adopts (registrar, then DNS, then WAF, then Workers) raises the switching cost of every other service, because the migration is no longer “point DNS at another CDN” but “rebuild four layers of your edge architecture simultaneously.”
Contract terms are the smaller half of the exit cost. The larger half is configuration with no portable representation: WAF rule sets tuned over years against your actual traffic, code deployed to the compute edge, DNS zones that export as files but lose their semantics, alerting wired to vendor-specific metrics. None of it moves with a zone transfer. The migration that reads as one line item in the architecture review becomes a re-implementation project in the sprint plan, which is why second-CDN contracts get signed and then quietly never exercised.
This is why the vendor’s own numbers, discounted as marketing, still matter for risk planning. A vendor claiming reach across 335+ cities is telling you that its network is the low-latency option almost everywhere your users are. That is precisely what makes leaving hard: any replacement delivers measurably worse latency in some geography, and that regression shows up in your dashboards the day you migrate.
One more scale signal: the vendor is actively shipping. The latest stable Cloudflare One Client for Windows is version 2026.7.1376.0, released 2026-08-28, within the last 30 days of this writing. Whatever else is true about the company, the product surface operators depend on is not stagnant.
What did the late-2025 outages actually demonstrate?
They demonstrated correlated failure: a single vendor incident took down services for major platforms internationally at the same time. Wikipedia records “significant global outages in late 2025” that disrupted major platforms, though the sources reviewed contain no post-mortem, no precise dates, and no per-platform impact detail, so the specifics should be treated as unverified beyond that summary.
Even without a post-mortem, the structural lesson does not depend on the root cause. When a large share of European commerce, media, and SaaS fronts its traffic through one edge network, that network’s failure mode becomes a synchronized failure mode for its customers. A DDoS mitigation provider going down is different from a single origin going down: every customer fails simultaneously, support queues saturate globally at once, and status-page communication degrades exactly when everyone needs it. The late-2025 incidents turned an abstract concentration argument into an observed event.
A global edge network is one failure domain by design. The shared routing and control plane that make regional failover invisible on a normal day are the same components that can propagate a control-plane defect to every point of presence at once. Incident response assumes the opposite: on-call rotations, support staffing, and status-page cadence are sized for failures that arrive at a normal rate, not for every customer of one vendor paging their teams in the same five minutes. Queue saturation, not the underlying defect, is what turns an outage into a crisis, and it is the part an individual customer cannot fix.
The second-order effect is the one operators underprice. A Cloudflare incident is not a vendor problem you escalate to your account manager; it is a systemic event that your customers experience as your outage. Your SLAs pay out, your support channels absorb the load, and your post-incident review has a root cause you cannot fix. The concentration converts a third party’s reliability engineering into a line item on your own risk register, whether or not you consented to that arrangement.
When does multi-CDN failover collapse into one vendor?
When every fallback path, traced to its actual DNS resolution, terminates at Cloudflare anyway. This is the failure mode the 9-in-10 debate obscures: operators believe they have multi-CDN redundancy because their architecture diagram shows two CDN logos, while the traffic engineering underneath tells a different story.
The collapse happens through three common mechanisms. First, dependency stacking: your second CDN is genuine, but your DNS provider, your DDoS scrubbing, or your TLS termination is Cloudflare, so a Cloudflare control-plane incident takes down the switching mechanism itself. Second, hidden re-selling: smaller “independent” CDN and security vendors sometimes peer through or build on larger networks, and an operator discovers during an incident that the fallback was not as independent as the procurement slide claimed. Third, dormant failover: the secondary CDN is contracted but not warmed, with no TLS certificates provisioned, no cache filled, no runbook tested in the last year, so failover time is measured in hours rather than seconds.
Dependency stacking deserves a worked example, because it is the mechanism procurement never catches. Primary is vendor A, failover is vendor B, and both contracts look independent on paper. But the zone’s nameservers are hosted on the primary’s DNS, the TLS certificates renew through it, and the traffic-switching logic runs on it. When vendor A has a control-plane incident, the failover instruction cannot be served and the switching decision cannot be made. Vendor B was healthy the whole time. The organization paid for a second CDN and kept a single-vendor failure mode.
Dormant failover fails for budget reasons as much as technical ones. A warm secondary costs money every month in transfer, certificate operations, and engineering attention, and it produces nothing on any dashboard, so it is the line item quietly cut when budgets tighten. The outage then arrives with a cold cache, missing certificates, and a runbook nobody has opened since the person who wrote it left. Failover that has not been exercised within the last year should be modeled as recovery measured in hours, whatever the contract says about seconds.
The uncomfortable finding from this audit, in many organizations, is that true independence costs more than the outage risk appeared to justify until the late-2025 incidents repriced it.
What can EU regulators and auditors demand?
Across 27 member states, quite a lot, and the burden lands on operators rather than on Cloudflare. The European Commission proposes legislation, upholds the treaties, and ensures member states apply EU law, which is the channel through which resilience mandates reach your audit calendar.
The directional shift matters more than any single regulation: concentration converts outage planning from an engineering concern into a compliance artifact. When one vendor incident can simultaneously degrade commerce across multiple member states, regulators stop treating vendor selection as a private procurement choice. Auditors increasingly ask for evidence: documented dependency inventories, tested exit plans, concentration-risk assessments, and proof that failover was exercised rather than asserted. The late-2025 outages gave those auditors a concrete event to point at, and the 9-in-10 discourse, verified or not, gives them a narrative.
The artifacts themselves are unglamorous and cheap to produce on a quiet week: a dependency inventory that identifies serving networks by resolution rather than by contract, a concentration assessment naming the single points of failure, an exit plan with sequenced steps and named owners, and dated failover test records with measured timings. None of it requires new infrastructure. It requires stating in writing what the architecture actually depends on, which is the part organizations defer until an incident or a regulator forces the question.
None of the sources reviewed quantifies the European commerce impact of any specific outage, so any euro-figure you see attached to the late-2025 incidents elsewhere should be treated with the same skepticism as the 9-in-10 claim itself.
What should operators actually do?
Treat Cloudflare concentration as a plausible but unquantified systemic risk and act on the parts you can verify today. The checklist is short because the problem is structural, not informational:
- Audit the failover path by resolution, not by diagram. Trace where fallback hostnames actually serve from. If the answer is the same vendor as your primary, reprice the contract accordingly. Resolve from vantage points outside your own network: your resolvers can serve cached answers that flatter the diagram.
- Independence-test your second CDN. Get contractual confirmation that the fallback network is independently operated, and keep it warm: certificates provisioned, cache populated, failover timed in a live test. Re-run the drill after every significant change to the primary, because configuration drift is what turns a tested failover back into a dormant one.
- Demand methodology before citing concentration figures. The 9-in-10 European claim is single-source as of 2026-09-08. Use W3Techs’ 21.3% of all websites as the only independent anchor, with its denominator stated, until European-specific primary data surfaces.
- Write the resilience documentation now. Assume an EU auditor across the 27 member states will eventually ask what happens to your service when Cloudflare has a bad day, and have a better answer than “we have a status page subscription.” A dependency inventory plus a dated failover test answers most of the follow-up questions an auditor will ask.
The strongest limitation of this analysis deserves plain statement: the central 9-in-10 claim cannot be anchored to any fetched source, the outage references carry no post-mortem specifics, and no evidence in hand quantifies European commerce impact. Every downstream risk calculation inherits that unverified premise. What survives independent of the premise is older and more durable: a single edge vendor carrying this much traffic is a correlated-failure machine, most multi-CDN setups fail their first honest audit, and the late-2025 outages already demonstrated the blast radius once. The exact percentage is an argument for analysts. The failover test is a task for this quarter.
Frequently Asked Questions
How does the May 2026 restructuring affect incident response capacity?
The elimination of approximately 1,100 roles, or 20% of the workforce, attributed to AI adoption, reduces the human support and engineering base available during global outages. This contraction increases the risk that status-page communication and support queues saturate faster during correlated failures, as fewer staff are available to manage the surge in customer escalations.
What specific EU regulatory artifacts are auditors likely to request?
Auditors increasingly demand documented dependency inventories that identify serving networks by DNS resolution rather than contract, along with dated failover test records showing measured timings. These artifacts must prove that exit plans were exercised, not just asserted, converting vendor selection from a private procurement choice into a compliance requirement across the 27 member states.
Why is W3Techs’ 21.3% figure insufficient to verify the 9-in-10 claim?
W3Techs measures Cloudflare’s share of all websites globally, whereas the 9-in-10 claim targets European companies specifically using a CDN. The denominators are fundamentally different populations, making the independent telemetry non-comparable to the unverified European-specific assertion without a regional cut of the same methodology.
What is the operational cost of maintaining a warm secondary CDN?
A warm secondary incurs monthly costs for data transfer, certificate operations, and engineering attention to keep the cache populated and runbooks tested. This recurring expense is often cut during budget tightening, leading to dormant failover states where recovery time stretches to hours due to cold caches and missing TLS certificates.