The short answer: On October 20, 2026, Cloudflare One Gateway stopped passing traffic for roughly three hours whenever an identity-based policy was part of the decision, across every onramp into that Gateway. Our take is simple: when the policy decision lives in a vendor's cloud, one bug in that decision path becomes every customer's outage at once. dope.security evaluates policy on the device from a cached copy, so a bug in someone's cloud never decides whether your people can work.

This isn't a pile-on. Cloudflare found and shipped a fix in well under two hours, and its engineers are some of the best in the business. The point is architectural, and it's the same point we make in our comparison of Cloudflare's competitors and how Cloudflare One stacks up against Zscaler: where inspection and policy evaluation happen decides how wide the blast radius is when something breaks.

Below: what Cloudflare reported, why identity policies were the trigger, how this fits the pattern of cloud control-plane incidents across the category (see our breakdown of Zscaler's outage history and the control-plane problem), and what to ask any SWG vendor before your next renewal.

What happened to Cloudflare One Gateway on October 20, 2026?

Cloudflare's own status updates tell the story. Starting at 03:20 UTC, traffic through Cloudflare One Gateway failed specifically when an identity policy was present in the policy decision, and Cloudflare said the failure affected all onramps to Gateway. Gateway policies that did not include an identity condition kept working. The Cloudflare dashboard was also impacted during the incident.

By 04:40 UTC Cloudflare said it had identified the issue and was implementing a fix. By 04:44 UTC the fix was live and being monitored. At 05:46 UTC Cloudflare reported that edge functionality, including Access logins and Secure Web Gateway connectivity, was fully restored, while the Access API was still showing elevated error rates and latency. Third-party trackers that mirror the status page put full resolution between 06:14 and 06:34 UTC, for a total incident window of a little over three hours.

As of October 28, Cloudflare has not published a public post-mortem for this incident, so the root cause beyond “a bug in Gateway's identity-policy path” isn't on the record. We won't guess at it. What is on the record is enough to draw a lesson.

Why identity policies were the blast radius

Identity-aware policy is the whole point of a modern SWG. “Finance can reach the payroll app, contractors can't” and “only the corporate ChatGPT workspace is allowed” are identity decisions. Strip identity out of the rule set and you're back to blocking categories for everyone.

That's what makes this incident instructive. The customers hit hardest were the ones using Cloudflare One the way a mature security team should: with user and group conditions in their Gateway rules. The simpler deployments kept flowing. In other words, the more sophisticated your policy, the more exposed you were to a defect in the vendor's shared policy engine.

The failure also shows up in a place uptime monitors don't look. Third-party probes against Cloudflare's basic edge endpoints stayed green through the window, because the bug lived inside policy evaluation, not on the wire. Your users noticed. Your synthetic checks probably didn't.

The pattern: a shared cloud control plane is a shared failure

October 20 is one data point in a well-documented pattern across Cloudflare's network, and it rhymes with incidents at every cloud-proxy SSE vendor. Cloudflare's own post-mortems cover these:

• November 18, 2025: one oversized configuration file caused global 5xx errors for roughly five hours, taking down major sites that sit behind Cloudflare, including ChatGPT, X and Spotify.
• February 20, 2026: customer BYOIP prefixes were withdrawn via BGP for about six hours.
• January 2026: separate post-mortems on a 1.1.1.1 CNAME issue and a BGP route leak.
• November 2, 2023: during an incident, customers could not reach their logs.

Cloudflare declared its “Code Orange: Fail Small” resilience program complete on May 1, 2026. Credit where due: that's a serious engineering investment, and the speed of the October 20 fix reflects it. But customers report the incidents haven't stopped; a third-party compilation counted 13 status-page incidents between August 7 and August 14, 2026. And Cloudflare's status history shows another “Elevated Cloudflare Access API Errors” incident resolved on October 27, a week after the Gateway event.

Cloudflare's uniform anycast design means every location runs the same software and configuration, which is great for performance and consistency and less great for regional isolation when a bad change ships. None of this is unique to Cloudflare. Zscaler's October 25, 2022 incident (100% packet loss during internal maintenance) and Netskope's September 22, 2026 all-data-plane incident follow the same shape: the inspection cloud sits in the critical path of every request, so its bad day is your bad day.

The detour is also the dependency

Here's the part that gets lost in outage threads. Cloud-proxy SWGs don't just evaluate policy in the cloud; they route your traffic there. Every request goes device to point of presence to destination and back. That detour costs you latency on a good day (roughly 40 to 80 ms when users are close to a PoP and 150 to 400 ms when they're far from one), and it makes the vendor's cloud a hard dependency on a bad day.

Cloudflare's anycast network is fast and widely distributed, so the latency side of that tax is smaller than with some legacy proxies. The dependency side doesn't shrink with PoP count. If the policy engine in the path has a defect, the number of PoPs running that defect doesn't help you.

See the detour for yourself. Run the live Fly-Direct Speed Test on the dope.swg on-device secure web gateway page to measure what a cloud-proxy round trip adds to your own connection, or book a 20-minute demo and we'll run it with you.

Takeaway: every request that detours through a vendor cloud inherits that cloud's latency and its outages. Inspect on the device and you inherit neither.

How an on-device SWG handles the same failure

dope.security moved the secure web gateway onto the endpoint. The dope.swg Fly-Direct agent runs SSL inspection, URL filtering, Cloud Application Control and Dopamine DLP locally on Mac and Windows, then sends traffic straight to the internet. The policy decision is made from a locally cached copy of policy on the device. The cloud console distributes policy and receives telemetry; it is not in the path of each request.

That design changes what an outage looks like:

• Policy evaluation: Cloudflare One evaluates Gateway rules in Cloudflare's network, so a bug in that path hits every customer using the affected feature. dope.security evaluates rules on each device, so there's no shared policy engine for one defect to take down.
• Identity conditions: In a cloud-proxy model, identity lookups happen inside the vendor's service on every decision. With dope.security, user and group policy is pushed to the endpoint ahead of time, so the device already knows who it belongs to and which rules apply.
• Control-plane downtime: When a cloud SWG's control plane stumbles, traffic and visibility can go with it. If dope.security's console were unreachable, endpoints keep enforcing their cached policy in fallback mode; you lose the ability to change policy for that window, not the ability to browse safely.
• Blast radius: A defect in a cloud-proxy policy engine reaches every customer using that feature at once. With dope.security, enforcement is spread across independent endpoints, so there's no single shared engine for one defect to sit in.
• Latency: Cloud proxies add a round trip to a PoP on every request. dope.security adds no network detour, and the agent stays under 100 MB of RAM with up to 4x the performance of legacy proxy SWGs.

This is the architecture we wrote about in the pillars of perpetual uptime inside dopecloud: keep the cloud out of the request path and the cloud's bad day stops being your users' bad day.

Cloudflare One vs dope.security: a quick comparison

Cloudflare One is a capable platform and a 2026 Gartner Visionary in both the SSE and SASE Magic Quadrants. Here's how the two models compare on the questions this incident raises.

Cloudflare One Gateway

Cloudflare One routes device traffic through the WARP client into Cloudflare's anycast network, where Gateway applies DNS, network and HTTP policy. It's fast, globally distributed and tightly integrated with Cloudflare Access. The tradeoff is that policy evaluation for every customer runs on shared infrastructure, which is what turned a single identity-policy bug into a multi-hour, all-onramp incident. Full DLP, remote browser isolation, unlimited CASB and longer log retention are gated to Contract plans.

dope.security

dope.security runs the proxy on the device and flies direct to the destination. SSL inspection happens locally, so decrypted traffic never transits a shared cloud. Identity-aware policy, Cloud Application Control for corporate versus personal accounts, and AI-powered Dopamine DLP all run on the endpoint, and the console pushes policy changes to every device in seconds. If you're weighing options, our roundup of Cloudflare Zero Trust alternatives goes deeper on pricing and features.

What to ask your SWG vendor after October 20

Whoever you run today, these questions separate marketing resilience from architectural resilience:

• Where is the allow or block decision made for each request: in your cloud, or on the device?
• If your control plane or policy engine fails, what happens to user traffic? Fail open, fail closed, or keep enforcing a cached policy?
• Do identity-based rules depend on a live lookup in your cloud at request time?
• How do you stage policy-engine changes so one bad release can't hit every customer and every region at once?
• During an incident, can I still see my logs and dashboards?
• Will you publish a post-mortem, and how quickly?

A vendor with good answers will have them on paper. If the honest answer to the first question is “in our cloud,” the rest of the answers are about how they manage a dependency you can't remove.

What this looks like at enterprise scale

Architecture claims are cheap, so here's a deployment one. A Fortune 100 company scaled dope.security from 900 devices to more than 18,000 in a matter of weeks, averaging about 3,000 devices per week, deployed silently through Intune with no manual configuration. Because each endpoint enforces its own policy, scale doesn't concentrate risk in a shared engine. Adding 3,000 devices a week adds 3,000 independent enforcement points, not 3,000 more tenants on someone else's critical path.

The bottom line

Cloudflare fixed October 20 fast. The lesson isn't that Cloudflare is unreliable; it's that any SWG that evaluates your policy in a shared cloud makes that cloud's worst hour your worst hour, and the more identity-aware your rules, the more exposed you are. Put the decision on the device and a vendor bug becomes a vendor problem, not a company-wide outage. If that's the model you want, start a free dope.swg trial and see what flying direct feels like.

Frequently Asked Questions

What caused the Cloudflare One Gateway outage on October 20, 2026?

Cloudflare's status updates said traffic through Cloudflare One Gateway failed when an identity policy was present in the policy decision, across all onramps, while rules without identity conditions kept working. Cloudflare identified the issue by 04:40 UTC and had a fix live by 04:44 UTC. As of October 28, 2026, no public post-mortem detailing the root cause has been published.

How long did the October 2026 Cloudflare Zero Trust incident last?

The incident started at 03:20 UTC and ran a little over three hours. Cloudflare reported that Access logins and Secure Web Gateway connectivity were fully restored by 05:46 UTC, with lingering Access API errors resolved shortly after. The Cloudflare dashboard was also affected during the window.

Does an on-device SWG keep working if the vendor's cloud goes down?

It depends on where policy is evaluated. dope.security evaluates policy on each endpoint from a locally cached copy and keeps enforcing that policy if the console is unreachable, so browsing and protection continue while policy changes wait. A cloud-proxy SWG routes traffic through the vendor's network, so a cloud failure can interrupt traffic itself.

Is Cloudflare One still a good SSE choice after this outage?

Cloudflare One is fast and well engineered, and Cloudflare is a 2026 Gartner Visionary in both the SSE and SASE Magic Quadrants. The question is whether you're comfortable with a shared cloud policy engine in the path of every request, given incidents in November 2025, February 2026 and October 2026. Teams that want inspection and policy on the device choose dope.security instead.

How do I migrate from Cloudflare Gateway to dope.security?

Most teams run dope.security alongside their existing setup during a pilot, rebuild their Gateway categories and identity rules in the dope.console base policy, then deploy the agent through Intune, Jamf or Kandji. The free production trial converts to a paid account without reconfiguration, so there's no throwaway proof-of-concept tenant. Book a demo and we'll map your current rules with you.