Cloudflare ran four separate incidents on 30 September 2026, touching network performance in Madrid and Los Angeles, account permission changes, and Workers build delays. The longest of the four, the Madrid network issue, ran 43 hours 12 minutes before Cloudflare called it resolved. All four were faults on Cloudflare's side.
Started
10:31 UTC
Duration
Lasted 1d 19h
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, R2, Vectorize, API
What happened?
Cloudflare's status page logged four distinct incidents on 30 September 2026, starting at 10:31 UTC and running into the next day in two cases. The first was network performance trouble in Madrid (MAD), opened at 10:31, identified within an hour, and marked as fixed with monitoring by 14:06, though the incident itself stayed open for 43 hours 12 minutes before full resolution. The second affected account member roles and permissions, where recently changed permissions were not reflected immediately across some services, running 4 hours 37 minutes. The third was network congestion in Los Angeles (LAX), named by Cloudflare as hitting Vectorize, Durable Objects, R2, Hyperdrive, Stream and Cloudchamber, with two investigating updates and a duration of 5 hours 33 minutes. The fourth was a delay in Cloudflare Workers builds, affecting multiple customers by Cloudflare's own description, lasting 29 hours 58 minutes. Across all four, Cloudflare published nine updates in total, and none of them explain a root cause beyond naming the affected region or feature. The components list for the day spans Cloudflare Sites and Services, API, R2, Vectorize and Workers Builds, five in total. No user reports were filed during the window on this page, so everything here comes from Cloudflare's own status postings. Cloudflare's history shows 192 incidents in the last 90 days with a median duration of 1 hour 47 minutes, which makes the Madrid and Workers Builds incidents on this day well outside the typical length.
Learning
UptimeRobot's own probes, which check api-control, dns-1111 and edge-data from both the EU and North America every 60 seconds, recorded 100% uptime over 24 hours, 7 days and 30 days, and show no registration against this incident. That is not a contradiction. Cloudflare's incidents on this day were about specific regional network paths, account permission propagation and build pipeline delays, none of which necessarily break a basic reachability check run from outside. A probe hitting Cloudflare's edge from Frankfurt or Virginia can get a clean response while a customer in Madrid or Los Angeles, or a developer waiting on a Workers build, sees real delay or congestion. This is the usual shape of a partial, component-level outage: broad enough for Cloudflare to post four separate incidents, narrow enough that an external synthetic check sampling a handful of endpoints from a handful of regions stays green throughout. Your own uptime monitoring tells you whether your product's endpoints are reachable, which is only half the picture when the fault sits inside a provider's network or build infrastructure rather than at your door. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.</learned>
