Cloudflare 522 is a timeout between Cloudflare and the origin, not simply “a slow WordPress page”. The useful question is where the connection stops progressing: network path, firewall, exhausted server, web listener or an origin that accepts sockets but cannot answer in time.
Establish whether the origin is intermittently reachable
Run repeated direct-origin checks from more than one network. Intermittent success points toward saturation or filtering rather than a fixed DNS error.
Compare connection time with application time
Measure TCP/TLS establishment separately from time to first byte. A 522 before useful HTTP evidence should not be debugged by optimizing a template.
Inspect capacity at the incident time
Check CPU, memory pressure, connection queues, PHP workers and provider graphs around the exact failures. An average daily chart can hide a five-minute saturation event.
Review firewall and rate-limit rules
A firewall can silently drop Cloudflare traffic instead of rejecting it, producing a timeout rather than 521. Correlate blocked source ranges and rule hits.
Check the network path and provider
If the host itself is healthy, compare routes and packet loss from external probes. Escalate with timestamps and source/destination evidence, not “Cloudflare is down”.
Retest under representative load
After recovery, test uncached dynamic routes as well as cached pages. A warm homepage can look healthy while checkout or admin still exhausts the origin.
Compare application-side timeouts with the WordPress 504 guide and rule out a stale target with the DNS migration check.