Cloudflare errors 522 and 524 both involve communication with the origin server, but they point to different stages of a request. Record the code, affected URL, time and timezone before asking the host to investigate.
Use Cloudflare’s official 522 guidance and 524 guidance alongside the origin logs. The exact code helps distinguish connection problems from a server that connects but responds too slowly.
A 522 means Cloudflare timed out contacting the origin, either during connection establishment or while waiting for acknowledgement of a request. Check whether the origin is online, whether the configured origin IP is correct and whether firewall or security rules are blocking Cloudflare connections. Server overload and network routing problems can produce similar symptoms.
A 524 means Cloudflare connected to the origin, but the origin did not return an HTTP response in time. Look for slow PHP processes, expensive database queries, long-running imports or other application work. Simply retrying may hide the symptom without addressing the slow origin process.
Where appropriate, test the origin independently of the proxy so you can distinguish a Cloudflare-layer issue from a slow or unavailable server. Review server and application logs around the failure time. Do not permanently weaken firewall protection just to make the error disappear; identify which legitimate traffic needs to be allowed.
If the error appears only at busy times, compare timestamps with CPU, memory, database and PHP worker utilisation on the origin. Intermittent 522 or 524 responses can indicate capacity or application-performance problems rather than a permanent configuration fault. Monitoring over time is more informative than repeatedly refreshing the affected page after traffic has fallen.
After the provider fixes the cause, retest the affected request. Compare the new logs with the original failure time. If the origin reports a PHP memory problem, our WordPress memory-limit guide explains how to investigate that layer.
Give support the exact affected URL, error code, time and timezone. Include the Ray ID from the error page when available. Note whether the problem affects the whole site or only a particular action, such as an import or form submission.
Record recent hosting, firewall, DNS or application changes. Avoid repeatedly changing unrelated settings while the provider investigates. For long-running tasks, ask the developer whether the operation should run in the background rather than inside a visitor request.
Test the original failing journey, not only the homepage. If the failure involved a submission, check whether the first attempt already created a record before retrying. This helps avoid duplicate orders or enquiries. Monitor the same workflow during normal traffic and record any recurrence for the provider.