A 524 Is Not an Origin Diagnosis
Trace the route before changing the origin.
Update, 15 October 2026: Cloudflare marked the incident resolved at 11:28 Madrid, following its 14 October fix-and-monitoring update. No further repair detail was published.
The incident began on 10 October. The 12 October notice refined its scope rather than announcing a separate outage.
The report narrowed the traffic path
The reports concerned mainland Chinese public-internet routes to overseas origins, across several ISPs. Users saw slow transfers and timeouts; Cloudflare did not identify the affected cities, provinces or providers.
On 12 October, its 06:23 Madrid update placed congestion upstream and warned of recurring 524s. At 17:33, it attributed China Network latency and 5xx errors to cross-border instability and described routing changes with partners.
A 524 does not locate the fault
Cloudflare’s 524 documentation describes a completed origin connection followed by a response or write timeout. That does not identify the cause. Restarting services may leave the constraint untouched.
The 12 October revision changed the first question. Instead of assuming an origin failure, ask whether the affected request crossed the path described in the incident. Keep other explanations open until the evidence separates them.
Build a route-specific evidence set
BlackTree guidance: Group reports by client city or province, ISP, Cloudflare colo, origin region and timestamp. Compare failing and successful requests across those dimensions. Preserve Cloudflare Ray IDs where available, then correlate them with edge, load-balancer and origin logs.
A connection alone does not prove that the application completed the work. Correlate request timings with queues, application processing and downstream calls, then compare successful and failed journeys. Use those differences to test competing explanations, not merely to confirm the first hypothesis.
Retry with uncertainty in view
Use bounded retries with backoff and jitter, and replay only operations that are safe to repeat. Protect writes with idempotency controls. A burst of automatic retries can increase load at the origin or on a constrained route, so set a retry budget and expose exhausted retries in monitoring.
Keep the incident as one working hypothesis rather than a universal explanation. Record the route attributes that support it, the evidence that would disprove it and the time of the last provider check. Recheck the incident record before acting on its status.
