Blog

When monitoring at 16:27 was not the end

2026-10-24

On 23 October 2026 Cloudflare set a North America connectivity incident to monitoring at 16:27 UTC. The provider failed again at 17:03. Resolved at 18:43 left a Workers cron incident open, and Ashburn opened a new filing at 01:01.

At 16:27 UTC on 23 October 2026 Cloudflare set incident sufgcbe8rrwt to monitoring and wrote that a fix had been implemented. At 16:59 the same incident moved back to identified. At 17:03 they wrote that the infrastructure provider had a recurrence of the failure. The resolved line at 18:43 closed that incident ID. It did not close Workers Cron Triggers, still open until 20:37, and it did not name the Ashburn filing that opened at 01:01 the next morning.

What the North America page said

The clocks below are the update times on sufgcbe8rrwt, in UTC. Technobezz recorded the same sequence in Eastern time, from 11:47 a.m. investigating to 2:43 p.m. resolved. UptimeRobot lists it as a major incident starting at 15:47 UTC and lasting 2 hours 56 minutes, which matches the resolved time on Cloudflare's page.

• 15:47 UTC: investigating. Degraded network performance on some traffic between the Ashburn and Atlanta data centers. Some customers might see increased latency, packet loss, or intermittent errors on Workers and other services in the Eastern US. The component update on that post moved Network from operational to degraded performance.
• 16:07 UTC: identified. A connectivity provider outage, causing congestion and degraded performance for some customers in North America. Cloudflare said it was rerouting traffic away from the affected paths.
• 16:27 UTC: monitoring. "A fix has been implemented and we are monitoring the results."
• 16:59 UTC: identified again. "We are continuing to work on a fix for the issue."
• 17:03 UTC: "The infrastructure provider has experienced a recurrence of the failure." Traffic management continued.
• 17:33 UTC: still routing around the impacted paths, until packet drops were mitigated.
• 18:18 UTC: monitoring. Traffic had been rerouted and they were no longer seeing packet drops. The connectivity provider reported that its service had been restored, but some links were still being brought back, so Cloudflare was keeping the traffic management changes in place.
• 18:43 UTC: resolved. The body of that update is one sentence: "This incident has been resolved."

The 18:43 sentence does not say the links finished coming back. The 18:18 sentence is the last one that describes the path. A customer update that keeps the resolved line and drops the links sentence has thrown away the only scope Cloudflare had left on the page.

The resolved line left another incident open

Twenty minutes before sufgcbe8rrwt opened, Cloudflare opened incident 3ts1mfzs0khz. At 15:27 UTC they were investigating Workers Cron Triggers running late, being skipped, or running more than once. That update moved the Workers component from operational to major outage. Technobezz's note on that incident has the same ends: investigating at 11:27 a.m. Eastern, resolved at 4:37 p.m. Eastern, which is 20:37 UTC.

At 18:43, when the North America incident became resolved, 3ts1mfzs0khz was still investigating. Its monitoring update is 20:29 UTC, and on that update the Workers component stays major outage. The resolved update at 20:37 UTC moves Workers back to operational. For the two hours after you might have pasted "Cloudflare resolved," the cron incident was still the one holding Workers.

A host that answers while a scheduler misses is a different question, and that writeup is when the cron is late and the host still answers. The fact to add on 23 October is that the cron incident ID outlived the network incident ID.

Ashburn opened a new ID at 01:01

At 01:01 UTC on 24 October Cloudflare opened incident 39fz3wkl42tr, minor impact, titled network performance in Ashburn, VA. At 01:05 they named the affected services: Durable Objects, R2, Workflows, Queues, D1, and Artifacts. The location on the page is Ashburn (IAD). Monitoring at 01:28. Resolved at 03:09. sevanalysis lists this filing separately from sufgcbe8rrwt, with the same product list and a duration of 2 hours 8 minutes.

Cloudflare does not say 39fz3wkl42tr continues the connectivity-provider failure. The product list is not the product list on the 15:47 update, which named Network. Copy that treats the 01:01 page as an update to sufgcbe8rrwt is guessing a cause the vendor did not publish.

Copy you can adapt

The weak version, which could be pasted onto any incident:

Cloudflare resolved the North America network outage at 18:43 UTC. All services are operational. We will post again if anything else comes up.

That paragraph costs the next two clocks. A reader at 19:10 sees operational and does not open 3ts1mfzs0khz, so a cron run that was late, skipped, or doubled has no sentence on the page. A reader at 01:20 still has yesterday's resolved line, and an R2 or Durable Objects error looks like their own bug, because 39fz3wkl42tr is not the incident they were given.

Two updates that keep the IDs apart:

18:50 UTC, 23 October. Cloudflare incident sufgcbe8rrwt, traffic between Ashburn and Atlanta, was set to resolved at 18:43 UTC. At 18:18 they wrote that packet drops had stopped after a reroute, that the connectivity provider reported its service restored, and that some links were still being brought back, with traffic management kept in place. This incident had already moved to monitoring at 16:27 and back to identified at 16:59, after the provider failed again at 17:03. 18:43 closes sufgcbe8rrwt only. Incident 3ts1mfzs0khz has been open since 15:27 UTC for Workers Cron Triggers that run late, get skipped, or run more than once. On that incident the Workers component is still major outage. Scheduled jobs stay in incident until that ID resolves.

01:10 UTC, 24 October. At 01:01 UTC Cloudflare opened incident 39fz3wkl42tr for network performance in Ashburn. At 01:05 they named Durable Objects, R2, Workflows, Queues, D1, and Artifacts. This is not sufgcbe8rrwt, and they have not said the two share a cause. Writes that depend on those products stay failed or slow until this ID says otherwise. Yesterday's resolved line does not cover them.

A reader who was not on the bridge can check each sentence against the three incident pages. The weak paragraph cannot be checked, so it cannot be trusted an hour later.

What not to do

• Do not paste "a fix has been implemented" from a monitoring update as the customer note. On this incident that line was 16:27, and 17:03 said the provider had failed again.
• Do not drop the 18:18 links sentence when you copy the 18:43 resolved line.
• Do not close every Cloudflare symptom because one incident ID resolved. At 18:43 the cron incident was still open, and Workers on that incident stayed major outage until 20:37.
• Do not file the 01:01 Ashburn notice under yesterday's ID. Durable Objects, R2, Workflows, Queues, D1, and Artifacts were named on 39fz3wkl42tr.
• Do not tell customers the two Ashburn filings share a cause. Cloudflare did not say that.

Operator checklist

1. Write the incident ID on every sentence you copy. sufgcbe8rrwt, 3ts1mfzs0khz, and 39fz3wkl42tr are three filings.
2. When status moves to monitoring, keep the clock. If the next update returns to identified, the monitoring line was not the end.
3. Read the update before the resolved line. On sufgcbe8rrwt that update is the one about links still being brought back.
4. Check which component that ID changed, and which other open ID still holds a component. The cron incident held Workers at major outage from 15:27 to 20:37.
5. After an ID resolves, watch for a new ID in the same city before you tell customers the city is quiet.

The public Cloudflare page at /status/cloudflare probes www.cloudflare.com and puts that reading next to the vendor feed. On 24 October 2026 at 15:35 UTC the host was reachable, and the page listed no independently measured reachability incidents from 17 October 15:35 UTC through that reading. A homepage that answers does not measure packet loss between Ashburn and Atlanta, and it does not measure Durable Objects, R2, Workflows, Queues, D1, or Artifacts. Those stay on the incident IDs. Reachable means the host answered.