Cloudflare opened a major incident at 15:47Z on October 23, citing degraded performance between Ashburn and Atlanta, with latency, packet loss, and intermittent errors hitting Workers and other services across the Eastern US. By 16:07Z the company said a connectivity provider outage was the cause and that it was rerouting traffic. That looked like containment. It was not. At 17:36Z the incident was still listed as identified, not resolved, after Cloudflare reported a recurrence of the same upstream infrastructure failure. Traffic engineering was ongoing as teams worked to stop the packet drops.
Separately, a minor incident opened at 15:27Z covering delayed, missed, and duplicated Workers Cron Triggers. As of its last update at 16:12Z, that one was still in investigating status, with no stated cause and no confirmed link to the Ashburn-Atlanta routing problem. Cloudflare has not said whether the two incidents share a root cause. That absence matters. For engineers trying to triage, two open tickets with overlapping timing and no confirmed relationship is a worse position than one.
What is confirmed: a third-party connectivity provider failed, Cloudflare rerouted traffic once, and the same failure recurred afterward. What is reported but not fully explained: the scope of affected Workers traffic beyond the Eastern US corridor, and whether rerouting degraded performance elsewhere while fixing Ashburn-Atlanta. What is unknown: the provider's identity, the fix timeline, and whether Cron Trigger irregularities stem from the same network path or a separate fault in the scheduling layer. Cloudflare's status page does not say.
On-call engineers should treat the recurrence as the operative fact, not the initial fix. A single reroute that holds is routine. A reroute that fails again within roughly ninety minutes means the underlying path is unstable, and anything depending on consistent latency to Ashburn or Atlanta, including session affinity, retry budgets, and queue backpressure, is now running on borrowed time. Check Workers invocation error rates by region, not just aggregate dashboards. If your deployment pins traffic through the Eastern US or depends on Cron Triggers for billing, cleanup, or health checks, assume jobs may run late, run twice, or not run at all until Cloudflare confirms resolution.
The gap between the two incidents is where the real risk sits. A platform operator reading only the major incident might assume scheduled jobs are unaffected since Cron Triggers has its own ticket. That assumption is untested. Cross-check logs for duplicate cron executions against the 15:27Z window, and treat any idempotency gaps in downstream systems as exposed until Cloudflare closes both incidents.
Neither incident had a resolved timestamp as of 17:36Z. The packet loss mitigation was still active, and the Cron Triggers fault was still under investigation, with no stated connection between the two.