Cloudflare had four separate incidents on 24 September 2026, touching Access, Browser Isolation, Workers Builds and a backend component tied to Replicate. The longest ran 5h 14m, and all four were Cloudflare's own infrastructure problems, not yours.
Started
15:20 UTC
Duration
Lasted 3h 8m
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, Workers Builds, Browser Isolation, Access
What happened?
The day's first incident started at 15:20 UTC, when Cloudflare engineering reported a delay in Access configuration updates, including applications and policy updates. Cloudflare was explicit that authentication and policy enforcement themselves were not affected, only the propagation of changes. A fix was applied eleven minutes later, and the incident closed after 3h 8m total. At 17:26 UTC a second, unrelated incident began: Browser Isolation's session data sync broke, and Cloudflare said customers could see errors claiming browser storage was unavailable, forcing users to sign back into web apps. Cloudflare noted browsers themselves kept working during this. That one ran the longest of the day, 5h 14m, though a fix was reportedly implemented just two minutes after the identification update. Seven minutes after Browser Isolation started, at 17:33 UTC, Cloudflare Workers Builds began showing delays starting new builds, which Cloudflare attributed to queue backlog; by 19:54 UTC it reported queue levels and latency returning to normal, and the incident closed at 3h 22m. The final incident of the day, starting 20:40 UTC, involved a backend component that Cloudflare said entered an unexpected reboot, causing downstream issues for services including Replicate, lasting 1h 55m. Across all four incidents, Cloudflare published seven updates total, and no further detail or post-mortem has been added since each incident's closing update. No user reports were filed during the window.
Learning
UptimeRobot's own probes against Cloudflare's control plane and edge components, run from EU and NA regions every 60 seconds, stayed at 100% uptime across 24 hours, 7 days and 30 days. That is consistent with what Cloudflare described: these were faults in specific internal systems, Access's config propagation path, Browser Isolation's session sync, the Workers Builds queue, and a backend reboot affecting Replicate, none of which necessarily break a basic reachability check against the edge. A synthetic probe hitting DNS or the edge data path has no way to see a stuck build queue or a session sync delay several layers deeper in the stack. This is the general shape of these failures: the edge can answer every request correctly while a specific feature behind it quietly misbehaves for hours. If your product depends on Workers Builds, Access policy updates or Browser Isolation specifically, a green uptime check tells you nothing about that dependency. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
