Cloudflare had four separate incidents on 3 November 2026, touching Containers, network performance in APJC, Workers and Pages builds, and Durable Objects in Dallas. The longest, a Workers and Pages build failure, ran for 4h 53m and was Cloudflare's fault, not yours.
Started
04:12 UTC
Duration
Lasted 1h 14m
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, Workers Builds, Network, Containers
What happened?
Cloudflare logged four incidents across the day, starting at 04:12 UTC and running through to the Workers and Pages build issue resolving at 19:39 UTC based on its 4h 53m duration. The first, Container start failures, lasted 1h 14m: Cloudflare said it was "investigating an increased level of errors for Containers failing to start," identified a fix at 05:07, and marked it resolved by 05:12. A second and overlapping incident hit Network Performance in the APJC region starting 04:44, also running 1h 14m, with a fix implemented and monitored by 05:49. The biggest incident of the day began at 14:46 UTC, when Cloudflare flagged "Cloudflare Workers and Pages build failures which potentially impacts multiple customers." That update escalated to note "increased queue times for Workers Builders," and by 17:23 Cloudflare said queue times were returning to normal, telling customers with failed builds to retry via the dashboard or push a new commit. A fourth incident, increased Durable Object errors in Dallas, Texas, started at 15:38 and was down to monitoring by 16:13, a total of 1h 5m. None of the four incidents came with a published post-mortem explaining root cause, only the status updates above. No user reports were filed during the window for any of the four incidents. Cloudflare's own component list names five affected services: Cloudflare Sites and Services, Containers, Network, Workers Builds, and Durable Objects.
Learning
UptimeRobot's own probes against api-control, dns-1111 and edge-data, from both EU and NA regions, stayed at 100% uptime over 24 hours and 7 days, and 99.996% over 30 days, straight through all four incidents. That is not a contradiction. Container starts, Workers Builds queuing, and Durable Object errors in one region are failures inside specific product paths, not failures of the edge network paths that basic uptime checks hit every 60 seconds. A build failing to start or a Durable Object throwing errors in Dallas will not show up as downtime on a simple ping or DNS check, because the check never exercises that code path. This is the general shape of a platform-layer outage: the provider's status page and your own monitoring can both be telling the truth at once, because they are watching different layers. If your product depends on Workers Builds or Durable Objects specifically, your own endpoint checks would have stayed green while your builds queued or your objects errored, and you would have had no way to tell from your own dashboards which side had broken. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
