A Cloudflare outage on October 20, 2026 broke real traffic through Cloudflare One Gateway for three hours and fourteen minutes, and the uptime monitors watching Cloudflare's own edge components never registered it as a hit. The bug only fired when a specific condition was present in a policy decision, which is exactly the kind of fault that a health check hitting a basic endpoint is built to miss.
Jump to what we checked in our own monitoring setup if you run synthetic checks against any policy-gated service.
Two Incidents, One Shared Shape
The first incident started at 03:20 UTC and ran until 06:34 UTC. According to Cloudflare's own status page, traffic through Cloudflare One Gateway failed specifically when an identity policy was present in the policy decision. That affected every onramp into that Gateway, while Gateway policies with no identity policy attached kept working the whole time. The Dashboard was also affected, under investigation alongside the main issue.
Cloudflare said the problem was identified by 04:40 UTC and a fix was live four minutes later. But the Access API still showed higher-than-normal error rates and latency at 05:46 UTC, even after edge functionality, including Access logins and Secure Web Gateway connectivity, had already been fully restored. The Access API issue wasn't closed out until 06:14 UTC. That's six separate status updates across nearly three hours of active engineering work before the incident reached full resolution.
A second, smaller incident started at 19:35 UTC and lasted 41 minutes. Cloudflare's Bot Management feature began incorrectly flagging a limited number of verified bots as automated traffic. Only one update was ever filed for it, so there's no public detail on what caused the misclassification or exactly how it was fixed.
Neither incident has a published post-mortem as of this writing. Cloudflare's status page is the only source for both, and the company has not said whether the two bugs share a root cause, though the shape of the failure is the same in both cases: a logic error in how a request gets classified or evaluated, not a connectivity drop between a client and Cloudflare's edge.
Why Every Synthetic Monitor Came Back Green
This is the detail worth sitting with. Monitoring services running independent checks against Cloudflare's api-control, dns-1111, and edge-data components in the EU and NA regions logged 100% uptime over the following 24 hours and 7 days, and 99.996% over 30 days. The October 20 incident never registered as a hit against any of those probes, and that's not a contradiction in the data. It's a description of exactly what kind of bug this was.
The failure only showed up when an identity policy was present in a Gateway decision. A synthetic check that pings a basic edge path, or hits a health endpoint that doesn't carry an identity policy through the same decision logic, will never exercise the exact code path that broke.
It will ping, get a 200, and move on, while a real user authenticating through that exact Gateway onramp gets nothing. The bot misclassification 16 hours later is the same failure mode at a smaller scale: a logic error in how traffic gets categorized, not a hard failure any uptime check is built to catch. UptimeRobot's own incident writeup puts it plainly: a narrow policy-path bug can break real traffic for real users while every synthetic check that doesn't exercise that exact path comes back green.
Does This Mean Uptime Monitoring Is Pointless?
No, but it means uptime monitoring answers a narrower question than most teams assume it does. A green dashboard tells you the wire between a prober and an edge endpoint is up. It does not tell you that every policy branch behind that edge is evaluating correctly for every class of request your actual users send. Those are different claims, and conflating them is how a three-hour outage can sit invisible on a status page that otherwise says everything is fine.
What We Checked in Our Own Monitoring
We checked what Krova Cloud's own external health checks actually exercise. The answer: an unauthenticated endpoint that returns a 200 as long as the API process is alive and can reach its database, which tells us nothing about whether identity-gated requests, like the ones our dashboard and billing API require, are evaluating correctly. We added a second synthetic check that authenticates as a real test account and walks through one identity-policy-gated action end to end, specifically so a bug shaped like Cloudflare's wouldn't sit invisible on our own status page the way it did on theirs.
What to Check in Your Own Setup
- Confirm whether your synthetic checks hit an unauthenticated health endpoint only, or whether at least one check exercises an identity-gated or policy-evaluated path end to end.
- If you run Cloudflare One Gateway or Zero Trust policies with identity conditions, add a check that specifically exercises an identity-policy branch, not just a bare Gateway onramp.
- Ask your status-page vendor or internal dashboard whether "all systems operational" reflects connectivity only, or actual successful policy evaluation for the request types your users send.
- If you depend on Bot Management for traffic decisions, log false-positive and false-negative rates separately from uptime, since a misclassification bug produces no downtime signal at all.
The honest limitation here is that neither Cloudflare incident has a public root cause analysis yet, so we don't know the specific code defect behind either the identity-policy failure or the bot misclassification, and we can't confirm whether they share an underlying cause or are coincidentally similar in shape. The 41-minute bot management incident in particular has only one line of public detail. Anyone citing a specific mechanism for that second incident beyond "misclassification" is speculating past what Cloudflare has published.
This is the same structural gap we found in AWS's own billing bug: the alarms existed, they fired on schedule, and the system still took hours to reach a human, because the thing the monitoring was built to catch wasn't the thing that actually broke.
The verdict: a green status page and 100% uptime readings from independent monitors are both accurate and both insufficient, because neither one was built to notice a bug that only fires inside a specific policy branch.
The rule: a synthetic check that never exercises your policy logic will tell you your wire is up long after your policy logic has stopped working, so at least one monitor you run needs to walk through the exact decision path your real users depend on, not just the connection in front of it.
FAQ
What caused the October 20, 2026 Cloudflare outage?
Cloudflare attributed the first and larger incident to a bug in Cloudflare One Gateway that caused traffic to fail specifically when an identity policy was present in the policy decision. The second, shorter incident involved the Bot Management feature misclassifying a limited number of verified bots as automated traffic. Cloudflare has not published a full root cause analysis for either as of this writing.
How long did the Cloudflare outage last?
The first incident ran from 03:20 to 06:34 UTC, about three hours and fourteen minutes, though the core fix was live by 04:44 UTC with a trailing Access API issue closed by 06:14 UTC. The second incident ran from 19:35 to 20:16 UTC, about 41 minutes.
Why didn't uptime monitors detect the Cloudflare outage?
Independent synthetic monitors checking Cloudflare's api-control, dns-1111, and edge-data components recorded 100% uptime through the period. The bug only triggered on requests where an identity policy was present in a Gateway decision, a condition that basic connectivity or health-endpoint checks don't exercise.
Was this a security incident or a breach?
No. Both incidents were internal logic bugs in Cloudflare's own policy evaluation and bot classification systems, not attacks, breaches, or exploited vulnerabilities.
I'm Rohit, founder of Krova Cloud: disposable, per-minute-billed VMs you can spin up specifically to run the kind of authenticated, policy-exercising health checks your main dashboard won't show you, torn down the moment the check is done. More debugging stories at debugly.dev.
Top comments (1)
The practical fix is a probe that exercises the condition, not the endpoint. If the failure only fires when an identity policy is attached, a check against a no-policy route stays green forever. A small synthetic that authenticates as a test identity and requests one resource through each policy class (identity-gated, device-gated, no policy) turns this class of outage into a red check. Alert on the result of the decision, for example expected 200 versus got a block page or timeout, rather than on connectivity. And keep one probe per policy class in the same dashboard so a single red tells you which class broke.