Cloudflare ran four separate incidents on 7 September, touching Workflows, its TURN relay service, Browser Isolation and the Dashboard UI. The longest, a Browser Isolation session failure, lasted 4 hours 53 minutes. None of this was caused by anything on your end.
Started
05:12 UTC
Duration
Lasted 2h 24m
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, Dashboard, Browser Isolation, Gateway, Realtime TURN Service, North America, Seattle, WA, United States - (SEA), Workflows
What happened?
The day started at 05:12 UTC with increased errors creating Workflow instances, a problem Cloudflare took 2 hours 25 minutes to resolve with no explanation of the root cause published beyond "a fix has been implemented". At 13:02 a second incident surfaced affecting the Realtime TURN service, and Cloudflare's own update noted this had actually been degrading performance since 22 August, with traffic wrongly relayed via TCP instead of UDP, hitting Chrome and other WebRTC-dependent connections with latency and lag. That one was marked fixed within 51 minutes of the public post, though the underlying problem had clearly been running far longer. At 14:25 a third incident began: Browser Isolation sessions failing to initialise, showing users a white screen when trying to reach isolated sites. Cloudflare identified a cause internally by 14:59 and rolled out a fix by 15:11, but the incident stayed open for 4 hours 53 minutes in total, and the update suggested affected users close all Browser Isolation tabs for two minutes as a workaround. A fourth, smaller incident overlapped from 15:32, where the Networking > Routes dashboard failed to render IP addresses, connector names and route descriptions correctly. Cloudflare was explicit that actual packet routing and API-based route management were unaffected, this was a display problem only. No post-mortem has been published for any of these four incidents, and no user reports were filed in this window that we have on record. Across all four, the record is limited to Cloudflare's own status updates, and each one moves quickly from investigating to a fix without stating why the fault happened in the first place.
Learning
Our probes against Cloudflare's api-control, dns-1111 and edge-data endpoints held 100% uptime across the 24 hour, 7 day and 30 day windows, and this incident was not registered against them. That is not a contradiction. These four incidents sat in Workflow instance creation, TURN relay performance, Browser Isolation session handling and a Dashboard rendering bug, none of which are covered by a synthetic check hitting core control and DNS endpoints. A product depending on Workflows, TURN relay, or Browser Isolation could have been failing for its users for hours while a simple uptime check against Cloudflare's edge stayed green the whole time, because the edge itself was fine. This is the general shape to watch for: the parts of a platform you rely on are not all the same parts a basic health check tests. Cloudflare's own history shows 194 incidents in the last 90 days with a median duration of 1 hour 48 minutes, so this kind of partial, component-specific failure is routine for them, not exceptional. Your own monitoring covers your half of the system. UptimeRobot now watches Cloudflare's half too, so next time a Cloudflare component breaks you will know which side it was on without guessing.
