Cloudflare's Spectrum service in Phoenix had an availability issue lasting 61h 38m. If you run Spectrum applications routed through that location, the fault sat with Cloudflare, not your own stack.
Started
00:59 UTC
Duration
Lasted 2d 13h
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, Spectrum
What happened?
Cloudflare's status page logged one incident on this day, titled "Spectrum Availability Issue in Phoenix", starting at 00:59 UTC. The listed components affected are Cloudflare Sites and Services and Spectrum. The first update, posted at 00:59, said Cloudflare was investigating issues with Spectrum in Phoenix that "may be impacting the availability of existing Spectrum applications," and that it was working to understand the full impact. A second update at 02:51, under a "monitoring" status, said Cloudflare was "continuing to monitor for any further issues." No further updates were filed after that. The incident's recorded duration is 61h 38m, which is how long it stayed open on Cloudflare's books even though the last public word came less than two hours in. Cloudflare has not published a root cause for this incident, and no closing update explains what the fix was or whether one was needed. No user reports were filed during the window on record. Over the prior 90 days, Cloudflare logged 205 incidents with a median duration of 1 hour 50 minutes, and this one ran well past that median on paper. Across its history, Cloudflare has recorded 3,491 incidents total. There is nothing here distinguishing a drawn-out technical fault from a status page entry that simply never got a closing update.
Learning
This incident was scoped to Spectrum in a single location, Phoenix, which is a specific TCP/UDP proxying layer, not Cloudflare's general edge network. UptimeRobot's own probes, covering api-control, dns-1111 and edge-data across EU and NA regions, held 100% uptime over 24 hours, 7 days and 30 days, and this incident was not registered against those checks. That is not a contradiction. Those probes watch core control and DNS paths that Spectrum issues in one city would not necessarily touch, so a clean probe history and a real, multi-hour Spectrum problem can both be true at once. If your product depends on Spectrum applications specifically, pinging your own endpoint from outside tells you your application responded, not whether the underlying Spectrum path in that region was degraded. That is the layer that failed here, and it sits below what a simple uptime check on your own domain would ever see. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
