Cloudflare Outage on November 18: What Happened

On November 18, many sites and apps reported intermittent errors or slow performance tied to Cloudflare. Because Cloudflare runs both networking and security at the edge, the same public “outage” label can hide very different root causes—DNS behavior, routing, TLS, cache/origin interactions, or rule/workers execution.

This guide focuses on what likely happened, how to verify the exact incident details for that date, and what to do if you run a site behind Cloudflare (or rely on one as an end user). You’ll also get concrete checks and failure-mode-specific troubleshooting so you’re not guessing during an active incident.

As an Amazon Associate I earn from qualifying purchases.

What happened during the November 18 Cloudflare outage

Cloudflare outages typically present as a partial or full degradation of request handling at the edge. Depending on the underlying issue, symptoms can look like DNS resolution problems, widespread 5xx responses (often 521/522/523), failed TLS handshakes, stalled page loads, or security products blocking more traffic than usual.

Because “November 18” isn’t enough to uniquely identify a single incident worldwide, the only reliable way to answer “what happened” for your specific case is to compare the date and the error pattern you saw against Cloudflare’s public incident reporting and your own logs.

How to confirm the exact incident details (timeline and scope)

Before you change configuration or start filing tickets, verify what Cloudflare says happened and when it started/ended. This reduces guesswork, especially if the event was regional or product-specific.

Use Cloudflare Status

Go to Cloudflare’s Status page and find the incident entry matching the November 18 date. Look for the “Affected services” list (for example DNS, CDN, WAF, Workers) and the timeline markers (identified, investigating, mitigations, resolved).

If you have multiple sites, confirm whether the affected services align with the stack you’re using: DNS only, reverse proxy/CDN, or additional features like WAF rules, Transform Rules, or Workers.

Check Cloudflare Radar (where relevant)

If your performance degraded, Radar can help you sanity-check whether traffic, latency, or error patterns changed across regions. Use it to separate “your origin is slow” from “edge delivery is slow.”

Radar won’t replace an incident report, but it’s useful when you’re correlating user complaints against global behavior.

Compare with your own logs and monitoring

Use at least three data sources: (1) your origin server logs, (2) your edge/CDN metrics, and (3) user-facing monitoring (synthetic checks or real-user monitoring).

• Origin logs: Look for spikes in requests or upstream timeouts during the incident window.
• Cloud-side logs/metrics: Check your Cloudflare analytics for error codes and product-level graphs.
• User monitoring: Confirm whether failures match 4xx vs 5xx, and whether failures cluster by geography/device.

If your origin did not receive traffic (or received far less than normal) while users saw errors, the problem is more likely edge-side routing, DNS, or TLS rather than your application.

Most common failure modes behind Cloudflare outages

Even without knowing the exact root cause for your incident instance, the playbook is easier when you map your symptoms to the likely failure mode.

Control-plane vs data-plane issues

Cloudflare’s “control plane” handles configuration and routing decisions, while the “data plane” handles actual request forwarding and content delivery. Outages can affect one or both.

If configuration changes appear inconsistent across users, it may be a control-plane issue. If requests start and then fail mid-flight, it’s more likely data-plane disruption.

DNS and routing disruptions

DNS-related problems often show up as NXDOMAIN, SERVFAIL, or long resolution times. Routing disruptions can show up even when DNS works—especially when traffic can’t reliably reach the correct edge endpoints.

Watch for patterns like: same domain works for some regions but fails for others, or your origin is healthy but clients can’t reach the edge properly.

Cache and origin shielding problems

If the edge cache is cold, unhealthy, or a purge/revalidation storm occurs, origin load can spike. In that case you might see timeouts, 5xx at the origin, or upstream connection errors that clients interpret as edge failures.

Strong signals: error spikes start right after a cache purge or a large deployment and correlate with a surge in “cache miss” metrics.

WAF, bot management, or transform rule misfires

Security products can effectively cause an “outage” by blocking legitimate traffic or breaking requests via request/response transformations. This can look like a sudden jump in 4xx (often 403) or in unusual error categories.

If your failures are mostly 403/406 or specific URLs, your incident may resemble a rule/config regression rather than a network-level failure.

Workers and integrations failing

Cloudflare Workers run at the edge and can fail if there’s a runtime error, a dependency issue, or a misconfigured binding (KV/R2/D1/secrets). When Workers fail, the symptom can be 5xx on specific routes while other routes remain fine.

If only some endpoints break (for example /api/*), prioritize checking the Worker route(s), deployment versions, and logs.

Certificate, TLS, and edge config issues

Edge TLS issues show up as handshake failures or browser/client errors. Sometimes you’ll see 525/526/525-style behavior or generic browser messages depending on how the handshake fails.

If everything fails at once for all URLs, certificate and TLS configuration is a top suspect—especially after a certificate change or a security settings update.

How the outage usually shows up (symptoms by product)

Use this mapping to narrow the scope quickly while you validate the incident timeline.

For websites and APIs

Common user-visible symptoms include elevated 5xx responses, long page loads, and intermittent “origin unreachable” style errors. If your origin is healthy, look for edge-to-origin connectivity problems or edge routing instability.

If failures are limited to specific routes, suspect Workers, WAF rules, or caching behavior tied to those paths.

For email and authentication flows

Email delivery “outages” are sometimes DNS/SMTP related. If your authenticated login flows fail while static pages load, suspect WAF rules, bot management, or TLS/session cookie behavior.

Check whether issues are tied to subdomains (for example login.example.com) and whether DNS records changed recently.

For mobile apps and CDNs

Mobile apps often have embedded DNS resolution patterns and aggressive retries. That can amplify errors, causing a thundering herd against the origin once the edge starts retrying or failing.

Look for a mismatch: mobile traffic spikes in errors while web users see fewer failures.

Immediate mitigation steps for site owners

If you’re operating a site behind Cloudflare and the November 18 outage affects you, focus on reducing uncertainty and limiting origin harm. These steps are designed to work even when you don’t yet know the exact root cause.

Step 1: Validate the blast radius

Decide whether it’s global, regional, product-specific, or route-specific. Compare your synthetic checks from multiple regions with your origin access logs.

• Are all URLs failing, or only a subset?
• Do failures match one hostname/subdomain?
• Do errors cluster around a particular country or ASN?

Step 2: Check whether the issue is Cloudflare-only

From a machine outside Cloudflare (or by using an alternate path), test your origin directly. If your origin responds normally over HTTPS, edge-side issues are more likely.

If you see origin-level 5xx as well, you may be dealing with an origin incident that Cloudflare is only exposing.

Step 3: Reduce edge-side dependencies

When the problem seems edge-side (or you can’t confirm origin health), temporarily simplify delivery:

1. Disable recently changed Workers/WAF rules affecting critical paths (if you can identify them).
2. Consider reducing custom error handling logic so clients receive consistent responses.
3. Temporarily narrow Transform Rules/response rewrites that touch high-traffic routes.

Make changes conservatively. If you have multiple rules, disable them one category at a time so you can attribute impact.

Step 4: Roll back recent changes

Most “outages on a platform” are amplified by a change you made right before the incident. If you deployed something around November 18, roll back or revert config changes.

1. Revert the last Workers deployment(s) for the failing routes.
2. Undo WAF rule edits or rule ordering changes.
3. Restore prior DNS records if you made a nameserver/CNAME/AAA/A change.

Step 5: Tune DNS and routing failover

If DNS behavior is part of your problem, use controlled failover so clients can keep reaching a working endpoint.

1. Ensure your DNS time-to-live (TTL) during the event is aligned with your resilience strategy (lower TTL helps faster recovery).
2. For multi-provider setups, verify that failover records are correct (A/AAAA, CNAME chains, and proxy settings).
3. Confirm that internal health checks align with what clients use (HTTPS vs HTTP, host headers, SNI).

Remember: if you proxy DNS with Cloudflare features, “DNS working” doesn’t guarantee “edge delivery working.” Validate both.

Step 6: Protect origin from thundering herds

When the edge is unstable, retries can spike origin load. Prevent overload so you don’t turn a Cloudflare degradation into a full origin outage.

1. Enable or increase rate limiting at the origin for high-risk endpoints.
2. Adjust upstream connection and request timeouts to fail fast during edge trouble.
3. Use circuit breakers in your application layer for downstream dependencies.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Troubleshooting when mitigation doesn’t work

If your site is still failing after the initial mitigation steps, use the error pattern and scope to choose the next move. Don’t keep flipping unrelated settings.

Origin is healthy, but edge still fails

Start with certificate/TLS and edge routing validation. Confirm that your origin hostname is reachable and that any “origin server” settings match your actual origin (hostname, scheme, port, Host header).

Then check whether the failing routes map to Workers or WAF logic.

DNS resolves but requests fail

This usually means the client can resolve to an IP or CNAME, but the request can’t be delivered correctly. Verify:

• Your DNS records point to the expected Cloudflare-proxied hostname.
• Your origin is reachable from the edge (network/security lists, firewall rules, TLS compatibility).
• No recent changes touched TLS mode, HSTS, or certificate chains.

Only some geographies or ASNs are affected

Regional impacts can be consistent with routing or data-plane issues. In that case, focus on user-experience mitigations (caching strategy, reduced computation at edge, and less brittle rules) rather than massive origin changes.

Use geo-segmented monitoring to confirm whether mitigation reduces errors everywhere or only in specific regions.

Errors change after cache purge

Purge events can cause cache revalidation storms. If you purged right before or during the outage, consider re-enabling stable caching behaviors and reducing traffic amplification by:

1. Confirm the correct Cache-Control headers are being served.
2. Check for expensive dynamic routes that accidentally got cached or repeatedly revalidated.
3. Verify stale-if-error and related behaviors are configured as intended.

What end users can do

If you’re just trying to access a site that’s failing, you have limited control—but you can reduce your chances of hitting a transient failure.

• Try reloading after a short delay (5–15 minutes). Edge routing and cache propagation issues often resolve in waves.
• Switch networks (Wi‑Fi ↔ mobile) or browsers to rule out local DNS/TLS caching problems.
• If the site is yours or you administer it, focus on your own incident channel: check your monitoring and your Cloudflare analytics/error codes first.

Preventing this class of outage impact

You can’t stop every platform incident, but you can reduce how much it hurts and how long it lasts for your users.

Operational controls

• Maintain a “known good” configuration snapshot for Cloudflare settings, WAF rules, and Workers versions.
• Keep deployments small and reversible. Prefer feature flags to large config rewrites.
• Run a quarterly restore test: verify that you can safely revert DNS and edge logic during an incident.

Technical resilience patterns

• Design origin servers to handle burst traffic (autoscaling, connection pooling, caching at the application layer).
• Use graceful degradation for non-critical features so the homepage and authentication remain stable.
• Separate routing for critical paths (payments, login, API auth) from experimental or heavy routes.

Runbooks, alerts, and testing

Create runbooks tied to error patterns you actually see: DNS timeouts, 521/522/523 behavior, TLS handshake failures, and WAF 403 spikes. Alert on both user-visible failures and origin health.

When Cloudflare status shows an incident, your runbook should already tell you what to check first, what to rollback, and what not to touch.

FAQ

Was the November 18 Cloudflare outage caused by a single bug or a specific rule?

Cloudflare incidents can be caused by infrastructure, configuration, or a product-level regression. The incident report on Cloudflare Status is the best source for the specific cause and affected services for that date.

Why did only some URLs fail during the outage?

Route-specific failures often come from Workers, WAF rules, custom caching behavior, or origin-specific dependencies. If static pages worked but API endpoints didn’t, that points away from global DNS issues.

Do DNS and CDN outages always happen together?

No. It’s possible to have DNS or routing problems without cache delivery issues, and vice versa. That’s why you should correlate Cloudflare incident “Affected services” with the exact symptom you saw.

What should I check first if I see 5xx errors?

Start with your error code distribution (what codes, what routes), then compare origin logs to Cloudflare edge analytics. If origin looks healthy and requests never reach it, focus on edge routing/TLS and recent edge-side changes.

Should I purge cache during a Cloudflare incident?

Purge can increase revalidation traffic and worsen overload. If you didn’t intentionally update content, avoid aggressive purges during an active platform issue. If content freshness is critical, purge narrowly to only the affected paths.

Bottom Line

The November 18 Cloudflare outage most likely affected request delivery at the edge in a way that your site experienced as DNS/routing/TLS problems, cache/origin instability, or product-specific rule/workers failures. The fastest path to an accurate “what happened” answer is aligning Cloudflare Status timeline and affected services with your own logs and error codes.

If you operate a site behind Cloudflare, the practical goal during an outage is simple: confirm scope, reduce edge-side complexity, roll back recent changes, and protect your origin from retry storms. That combination usually shortens incident time and prevents a partial degradation from turning into a full outage.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.