A 524 Is Not an Origin Diagnosis
Trace the route before changing the origin.
The incident began on 10 October. Its 12 October update is a scope revision, not a new outage.
The update narrows the traffic path
The provider says reports concern public-internet traffic between certain mainland Chinese cities or provinces and origin servers outside the region. Reports span multiple ISPs and include slower speeds or intermittent timeouts.
The 06:23 Madrid update placed congestion upstream and warned of intermittent 524 timeouts. At 17:33 Madrid, Cloudflare attributed latency and 5xx errors in certain China Network colos to cross-border routing instability. It was adjusting routes with network partners; no fixed resolution time was published when checked at 17:43 Madrid.
Cloudflare named no locations or ISPs, and its record does not explain every 524.
A 524 does not locate the fault
For operations, treat a 524 as timeout evidence, not a fault-location result. A healthy origin can still be reached through a congested path, while an unhealthy origin can produce a similar symptom. Restarting or scaling the origin without route evidence may add risk without touching the actual constraint.
The 12 October revision changes 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.
Check whether each request reached the origin. If it did, measure time spent in queues, application work and downstream calls. If it did not, compare route and loss observations from more than one network. This separates an origin capacity problem from a path-specific failure more reliably than the status code alone.
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.
