Cloudflare’s internal outage: why it can look like an attack, and how SMEs should prepare

On 18 November 2025, Cloudflare says a permissions update changed the results of a ClickHouse query: duplicate rows enlarged a Bot Management feature file beyond a software limit, causing 5xx errors. Its postmortem rules out an attack: core traffic was largely normal by 14:30 UTC, and all systems by 17:06 UTC. This retrospective separates those reported facts from the editorial recommendations below. (Cloudflare postmortem)

Why this matters for a small company

For a small or mid-sized business, the risk is rarely “the cloud is down” in the abstract. The practical problem is that one external service can sit under DNS, CDN, login, customer portals, status pages, and internal monitoring at the same time. If a provider fails, the impact can appear as several separate incidents: users cannot resolve names, cannot log in, cannot reach the portal, and the team cannot quickly tell whether the problem is local or upstream.

That is also why two vendors are not always true redundancy. If both depend on invisible shared layers — the same DNS ecosystem, the same identity provider, the same proxy path, or the same status workflow — the failure domain is still common. This is a general editorial assessment, not a finding about a specific customer or proof that every pair of providers shares these dependencies. Check the architecture before drawing that conclusion.

The practical SME plan

A resilient response plan does not try to eliminate every outage. It tries to prevent one outage from becoming a full business stop. A minimum viable plan has four parts: map dependencies, keep an independent status channel, define fallback and restore criteria, and rehearse a controlled test with named responsibilities.

1) Map critical dependencies

Start with the services that can block customers or internal operations if they degrade. The useful output is a simple record of the expected symptom, the owner, and the immediate action allowed during an incident.

2) Keep an independent status channel

Your status page should live outside the primary domain path you are trying to protect. It should be simple, low-dependency, and accessible without the same authentication chain. Include only what people need during an incident:

• service status,
• time of the last update,
• alternate contact method,
• instructions for degraded access.

If the main site is affected, the status page should still load on mobile and without a login barrier. The point is continuity of communication, not branding.

3) Define fallback and restore criteria

Before an incident happens, decide:

• who can authorize a tested alternative,
• how TLS, authentication, permissions and security controls remain effective,
• which portal functions become read-only,
• who approves rollback,
• what verification is needed before returning to normal.

Do not disable login or expose a protected origin directly to work around an outage. Without a tested alternative, suspend the restricted area. Read-only access to customer documents still requires verified identity and permissions. These decisions must be documented before an incident.

4) Run a controlled test

A test is not a marketing claim and not a synthetic benchmark. It is a rehearsal to confirm that people can follow the procedure under pressure. Use a test environment with fictional data to simulate slow DNS, unavailable login, and portal 5xx errors. A production exercise needs an approved plan, stop criteria and recovery procedure. The output to look for is not a saved percentage or a made-up performance gain. It is proof that the team can apply the fallback without confusion.

Simulated case: customer portal

Simulated scenario: an SME customer portal depends on a CDN, SSO, and backend APIs. The CDN vendor experiences an internal outage. A public holding page remains reachable through a tested independent path, but login fails.

Proposed response: the team publishes status on an external channel and suspends the restricted area. Read-only access is permitted only if authentication and permissions still work and have been verified; otherwise no customer documents are exposed. Editing, submission and payment stay suspended until recovery is verified. The goal is not to wait passively for the vendor to recover; it is to preserve partial service and communicate clearly.

Three checks to complete in one hour

1. The status channel is reachable without using the primary domain.
   • Who checks: operations or IT.
   • When: before any fallback test.
2. A runbook exists with named fallback and recovery decision-makers.
   • Who checks: IT lead or CTO.
   • When: during plan review, not during the outage.
3. The portal has at least one documented degraded mode.
   • Who checks: product owner and technical team.
   • When: after the controlled rehearsal, with the result recorded.

Limits and next steps

This checklist is an editorial proposal, not a universal runbook or a procedure approved by Cloudflare. Adapt and test it against your architecture. The example is fictional and does not describe a Dedaloop customer. The one-hour exercise covers initial documentation checks, not building or certifying a continuity system.

Start by describing the process you need to keep running: its dependencies, who authorises fallback, and how access controls and recovery are verified. That gives the team a concrete basis for a continuity plan and a useful starting point for discussing the project with Dedaloop.

Sources

• https://blog.cloudflare.com/18-november-2025-outage/