If your Cloudflare Workers builds failed to start on 3 October, the fault was on Cloudflare's side, not yours. The issue ran for 49h 34m according to Cloudflare's own status page before it was marked resolved.
Started
05:54 UTC
Duration
Lasted 2d 1h
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
What happened?
Cloudflare's status page logged one incident on 3 October, starting at 05:54 UTC, affecting Cloudflare Sites and Services and Workers Builds. The title Cloudflare gave it was "Issues with Workers Build failing to start", which matches a build pipeline fault rather than anything in the edge network or DNS layer. Cloudflare posted an investigating update at 05:54 UTC saying it was aware of and investigating the problem, and promised more updates shortly. The next and last update came three hours later, at 08:54 UTC, saying a fix had been implemented and they were monitoring the results. That is the entire written record: two updates, three hours apart, across a problem that Cloudflare's own timeline shows lasting 49h 34m before resolution. No further update narrows down what the fix actually changed, and no post-mortem has been published. No user reports were filed during the window on this page, so there is no first-hand account of what builds looked like while this was happening. Cloudflare's 90 day history shows 190 incidents with a median duration of 1 hour 48 minutes, so this one ran well past what is typical for them. Two components were listed as affected and nothing else on Cloudflare's status page moved during the window.
Learning
This incident sat entirely in Cloudflare's build pipeline, not in the edge network, DNS resolution or API control plane that most external monitoring checks against. UptimeRobot's own probes against api-control, dns-1111 and edge-data, run from the EU and North America every 60 seconds, showed 100% uptime over 24 hours, 7 days and 30 days. Both readings are correct: your product's requests through Cloudflare's edge kept working fine, while anyone trying to kick off a Workers build during that window hit a wall that had nothing to do with request routing. This is the shape to recognise: a build or deploy pipeline can be broken while every runtime check you have stays green, because the pipeline isn't in the request path your monitoring tests. Watching your own endpoints would only have told you your product was up, not that your next deploy was stuck. Cloudflare's 30 day stats show 59 incidents with a median duration of 2h 16m and 57 resolved, so build pipeline trouble is not rare for them even if it rarely shows up as downtime for you. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
