Cloudflare had a 19 minute spell of increased errors on Durable Objects and R2, tied to Amsterdam, starting at 20:59 UTC. The fault sat on Cloudflare's side and was fixed inside half an hour.
Started
20:59 UTC
Duration
Lasted 19m
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, R2
What happened?
Cloudflare's status page logged one incident on this day, starting at 20:59 UTC. The title was "Increased Errors for Durable Objects and R2", and the components listed were Durable Objects, R2 and Cloudflare Sites and Services, three in total. The first update said Cloudflare was investigating an increase of errors for Durable Objects and R2 "as a result in Amsterdam", and promised more updates shortly. Seven minutes later, at 21:06 UTC, Cloudflare posted that a fix had been implemented and they were monitoring the results. No further update followed, and the incident closed out at 19 minutes total. That is two updates in total, both shown here, and that is the full extent of what Cloudflare has said publicly about this event. No user reports were filed during the window, so there is no independent account of what this looked like from outside Cloudflare's own network. No post-mortem has been published, and Cloudflare's status page does not say what caused the errors beyond naming Amsterdam as a location. Over the last 90 days, Cloudflare has logged 192 incidents with a median duration of 1 hour 46 minutes, which makes this one short by comparison. Across all time, Cloudflare's own history shows 3,398 incidents.
Learning
UptimeRobot's own probes against Cloudflare's api-control, dns-1111 and edge-data components, run from the EU and North America, showed 100% uptime over 24 hours, 7 days and 30 days, and this incident was not registered against our monitoring at all. That is not a contradiction. A fault confined to Durable Objects and R2 errors tied to one location can sit entirely inside Cloudflare's backend logic, affecting specific API calls or storage operations without ever touching the basic reachability checks that external probes run. Your own monitoring, watching your application's endpoints, would have shown the same green result UptimeRobot's probes did, because your product's front door was never the problem. The failure here sat one layer down, inside the services Cloudflare runs behind that door, which is exactly the kind of fault that stays invisible to uptime checks pointed only at your own stack. Over the last 30 days Cloudflare has logged 69 incidents through UptimeRobot's tracking, 65 resolved, with a median duration of 1h 58m, so short, backend-level errors like this one are a regular occurrence rather than a rarity. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
