Cloudflare 524 Error: A Timeout Occurred - Causes and Fix

Error 522 means Cloudflare couldn't reach your server at all. Error 524 is different and more annoying: Cloudflare did reach it, the connection was fine, but your origin took longer than 100 seconds to send back a response. Cloudflare gave up waiting and showed the visitor "Error 524: A timeout occurred" instead of your page.

Why 524 Is Not a "Server Down" Problem

If you've read our guide on Cloudflare 521, 522 and 525 errors, you already know those codes point to a connection that never got established - a blocked firewall, a bad DNS record, a failed SSL handshake. 524 is the opposite problem. The TCP connection succeeded, Cloudflare's edge sent the request through, and your web server started processing it. It just didn't finish in time.

That's why refreshing the page sometimes "fixes" it - if the slow database query or plugin loop happens to run faster on the next attempt, the response comes back under 100 seconds and the page loads normally. That inconsistency is the biggest clue you're dealing with a genuine 524, not a server outage.

Common Causes

• wp-cron firing on a page load. WordPress's default pseudo-cron runs scheduled tasks (backups, cache warming, plugin update checks) whenever a visitor hits the site. If several tasks queue up at once, that single page load can take minutes.
• A slow or unindexed MySQL query. A WooCommerce report, a plugin doing a full table scan, or a poorly written custom query can hold the page open well past 100 seconds.
• A large export, import, or PDF/report generation running synchronously in the request instead of as a background job.
• An outbound API call that hangs. Payment gateway checks, license verification pings, or a third-party shipping-rate API with no timeout set can stall the whole request if that remote service is slow.
• PHP-FPM pool exhaustion. If all worker processes are busy, new requests sit in the queue before PHP even starts working on them, eating into the 100-second budget before your code runs a single line.

Diagnose It in a Few Steps

1. Note which URL actually threw the 524 - check your browser's address bar or the referrer in your access log. It's rarely the whole site; usually it's one specific page, endpoint, or admin-ajax action.
2. Grep your access log for that path and look at how often it's hit and by whom:

   grep "checkout" /home/username/access-logs/yourdomain.com | tail -50

3. Check the PHP slow log if you have one enabled, or turn on request_slowlog_timeout in your PHP-FPM pool config to catch exactly which script is running long:

   request_slowlog_timeout = 20s
   slowlog = /var/log/php-fpm/slow.log

4. Check MySQL's slow query log for anything tied to that same timeframe - see our MySQL slow query log guide if you haven't enabled it yet.
5. Test the URL directly against your origin IP (bypass Cloudflare with a hosts file entry) and time it with curl:

   curl -o /dev/null -s -w "Total time: %{time_total}s\n" https://yourdomain.com/slow-page/

   If it takes over 100 seconds even without Cloudflare in the path, you've confirmed the origin is the bottleneck, not the CDN.

The Fix

Here's the part that trips people up: you generally can't just raise Cloudflare's timeout. The 100-second edge timeout is fixed on Free, Pro, and Business plans and isn't exposed as a dashboard setting - only Enterprise accounts can request a higher connect/read timeout through their account team. So for almost everyone, the real fix is making the origin respond faster, not asking Cloudflare to wait longer.

If it's wp-cron

Stop WordPress from triggering cron on page loads and run it on a real schedule instead. In wp-config.php:

define('DISABLE_WP_CRON', true);

Then add a system cron entry that hits it every few minutes:

*/5 * * * * wget -q -O /dev/null https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

This spreads scheduled tasks out instead of dumping them all onto whichever unlucky visitor loads the page next. Our cron jobs in cPanel guide covers the exact steps if you're setting this up through cPanel.

If it's a slow query

Add an index on the column being filtered or sorted on, or rewrite the query to avoid a full table scan. If it's coming from a plugin you don't control, check for a newer version or an alternative - a report widget that queries wp_postmeta without an index is a classic culprit on stores with tens of thousands of orders.

If it's a heavy export/import or report

Move it out of the request-response cycle entirely. Use Action Scheduler (WooCommerce ships with it) or a proper queue so the job runs in the background and the user gets a "processing, we'll email you" message instead of a hung browser tab.

If it's a hanging external API call

Set an explicit timeout on the HTTP client making the call - most plugins default to no timeout or something absurd like 300 seconds:

$response = wp_remote_get($url, ['timeout' => 10]);

A slow third-party API should fail fast on your end and fall back gracefully, not hold your entire page hostage.

If it's genuinely a one-off heavy endpoint you can't speed up

You can take that specific subdomain or path out of Cloudflare's proxy so it connects directly to your origin (grey-clouding it in DNS), which removes the 100-second cap since the request no longer routes through Cloudflare's edge at all. This isn't ideal - you lose Cloudflare's protection and caching for that path - but it's a legitimate escape hatch for something like a long-running admin report that only staff ever touch.

Prevention

• Keep wp-cron off page-load triggers on any site with more than light traffic - system cron is more predictable and doesn't compound under load.
• Set timeouts on every outbound API call your plugins or custom code make. A missing timeout is the single most common cause of a 524 that "randomly" appears weeks after nothing changed on your end.
• Monitor PHP-FPM pool status (pm.status_path) so you catch worker exhaustion before it shows up as timeouts to visitors.
• Enable the MySQL slow query log permanently on production and review it monthly, not just when something breaks.
• For anything that could take more than a few seconds - imports, exports, bulk emails, PDF generation - default to a background job from the start instead of bolting one on after the first 524 shows up.

521 and 522 tell you Cloudflare never got an answer. 524 tells you it got one too slowly. Once you know which bucket you're in, the fix path is completely different - and for 524, it almost always lives in your code or your database, not in Cloudflare's settings.