Cloudflare's network hit congestion affecting Portland and Seattle in the US for 1h 49m on 22 October 2026. The fault sat inside Cloudflare's own network, not in anything you run on top of it.
Started
16:30 UTC
Duration
Lasted 5h 32m
Source
IsDown
Next time
Cloudflare is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Cloudflare Sites and Services, Durable Objects, Audit Logs, Zero Trust, North America, Ashburn, VA, United States - (IAD), CDN/Cache, Workers, Logs, Portland, OR, United States - (PDX), Seattle, WA, United States - (SEA)
What happened?
Cloudflare logged one incident on this day, starting at 00:23 UTC and lasting 1h 49m. The title Cloudflare gave it was "Network congestion in Portland and Seattle, US", and the affected components list names North America along with the Portland, OR (PDX) and Seattle, WA (SEA) points of presence specifically. Cloudflare's first update, also at 00:23, said it was "experiencing network congestion in Portland and Seattle, US" and working to mitigate impact to internet users in that region. A second update at 01:08, 45 minutes later, said a fix had been implemented and Cloudflare was monitoring the results. No further update followed, and no closing statement confirming resolution appears on the record beyond that monitoring note. No post-mortem has been published explaining what caused the congestion. No user reports were filed during the window, so there is no first-hand account of what this looked like from outside Cloudflare's network. Cloudflare's own 90 day history shows 192 incidents with a median duration of 1 hour 55 minutes, so this incident ran close to typical length for Cloudflare's own ledger. Across all time, Cloudflare has logged 3,439 incidents on its status page, which gives scale to how often entries like this one get filed.
Learning
UptimeRobot's own probes against Cloudflare's api-control, dns-1111 and edge-data components, run every 60 seconds across EU and North America regions, stayed at 100% uptime over 24 hours and 7 days, with 99.996% over 30 days, and this incident was not registered against those checks. That is not a contradiction. Cloudflare's congestion was scoped to two specific US points of presence, Portland and Seattle, and external checks hitting Cloudflare's broader edge or API surface from other regions can run clean while a narrow regional path is degraded for users actually routed through that path. This is the shape to recognise in your own product: a localised network problem inside a provider's infrastructure, invisible to synthetic checks that happen not to transit the affected region, but very real to anyone whose traffic does. Watching your own endpoints only tells you whether your service answered, not which leg of the journey, yours or Cloudflare's, carried the delay. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
