What Causes the “504 Gateway Timeout” in WordPress and How to Fix It

A 504 Gateway Timeout in WordPress means one server waited too long for another server to reply, then gave up on the request. On most stacks that cutoff lands somewhere between 30 and 60 seconds, which is why the error tends to appear on imports, checkout pages, or a slow admin screen rather than on your cached homepage. The page itself is rarely broken; something behind it is stalling.

What the Server Is Actually Telling You

A 504 is returned by a proxy, not by PHP. Your web server (usually Nginx or a LiteSpeed front end) passes the request to PHP-FPM, starts a stopwatch, and returns HTTP 504 when no response arrives in time.

That distinction matters for diagnosis. A 500 error means PHP ran and failed, while a 504 means PHP (or a service it depends on) is still chewing on the request when the clock runs out. In the Nginx error log you will typically see a line containing upstream timed out (110: Connection timed out) with the exact URI that hung.

The Causes We See Most Often

Roughly nine out of ten WordPress 504s we investigate trace back to a short list of culprits:

• A long-running PHP process: a bulk import, a WooCommerce order export, a 40,000-row post migration, or a backup plugin trying to zip 8 GB in one request.
• Slow database queries: unindexed meta lookups, a bloated wp_options table full of autoloaded transients, or post revisions piling up over the years.
• An external API that never answers: shipping rates, payment gateways, licence checks, or server-side analytics calls that have no timeout set.
• PHP-FPM worker exhaustion: every worker is busy, so new requests queue until the proxy times out. Traffic spikes and aggressive bots both trigger this.
• A firewall, proxy, or CDN layer sitting in front of the origin with its own, shorter limit.
• Undersized hosting: shared plans with hard CPU caps will throttle your account mid-request, and the stall looks identical to a code problem.

Five Checks Before You Edit Any Config File

1. Reload the URL two or three times. An intermittent 504 points to load or a flaky third party; a consistent one points to a specific slow request.
2. Note exactly which URL fails. If only /wp-admin/admin-ajax.php or a single product page times out, you already have your suspect.
3. Open the server error log and the PHP slow log. The slow log names the function that was running when the limit hit, which usually names the plugin.
4. Enable WP_DEBUG_LOG and watch /wp-content/debug.log while you reproduce the error.
5. Test with a clean query string such as ?nocache=1 so you are measuring the origin, not a cached copy.

Raising the Timeouts (And Why That Is Only Half a Fix)

Three limits need to agree with each other, and the shortest one always wins. PHP’s max_execution_time defaults to 30 seconds in many builds, while fastcgi_read_timeout or proxy_read_timeout in Nginx commonly sits at 60.

For a genuinely long job such as a one-off import, lifting all three to 300 seconds is reasonable. The PHP documentation on runtime configuration covers where each directive can be set, and on managed platforms these values are usually adjustable per site rather than server-wide.

Treat a raised limit as a bandage. If a front-end page needs more than about 10 seconds of PHP time, visitors and Googlebot have both left before the server finishes, so the real work is making the request faster.

Isolating the Plugin or Query That Stalls

SSH beats the dashboard here, because the dashboard itself may be timing out. Deactivating everything with a single WP-CLI command, then reactivating in batches, finds the offender in a few minutes; our WP-CLI command line guide walks through the syntax if you are new to it.

We cover this topic in more depth in How to Fix WordPress Image Upload HTTP Errors.

For a closer look at this topic, see our guide: How to Resolve the "502 Bad Gateway" Error in WordPress.

For database causes, enable the MySQL slow query log with a threshold of one second and reproduce the page. Autoloaded options over 1 MB, expired transients numbering in the tens of thousands, and related-posts queries scanning the whole postmeta table are the repeat offenders.

Outbound HTTP calls deserve their own look. Any integration that fires during page generation should carry a timeout of five seconds or less, which is one reason we prefer moving measurement work off the render path, as covered in our write-up on server-side tracking for Google Analytics 4.

Cloudflare, CDNs and the 524 Lookalike

If you sit behind Cloudflare, you will often get error 524 instead of 504 once the origin passes roughly 100 seconds. The meaning is the same: the edge stopped waiting.

Rule out the edge layer by requesting the origin IP directly, or by pausing the proxy for two minutes. A properly configured CDN layer also removes a large share of 504s simply by serving cached HTML and assets without ever touching PHP.

Preventing the Error From Coming Back

• Move heavy jobs to background workers. Replace WP-Cron with a real system cron running every minute, and let imports, exports, and emails run outside the request cycle.
• Cache aggressively at the page level. Full-page caching keeps PHP-FPM workers free for logged-in traffic and checkout.
• Size PHP workers to your traffic. A busy store needs more concurrent workers than a brochure site, and scalable hosting resources matter more than raw disk space.
• Keep the database tidy. Limit revisions, clear expired transients weekly, and index custom meta keys you query often.
• Roll back cleanly. Deploying through version control, as described on our Git-based WordPress hosting page, means a bad release can be reverted in seconds instead of debugged under pressure.

Sites that time out under a modest traffic bump are usually hitting a platform ceiling rather than a code bug, and even entry-level plans on a properly tuned stack behave very differently from oversold shared accounts. Our affordable WordPress hosting plans include LiteSpeed caching and per-site PHP tuning for that reason.

Frequently Asked Questions

How Long Does a 504 Gateway Timeout Usually Take to Trigger?

Most WordPress stacks return a 504 after 30 to 60 seconds, and Cloudflare-fronted sites after about 100 seconds. The exact number comes from the shortest timeout in the chain, which is usually PHP’s max_execution_time or the web server’s read timeout.

Does a 504 Error Hurt SEO?

A 504 lasting a few hours rarely causes lasting damage, but repeated timeouts over several days lead Google to reduce crawl rate for the affected URLs. Google treats persistent 5xx responses as a signal the site cannot be crawled safely, so pages can drop out of the index if the condition continues for weeks.

Can a Plugin Alone Cause a 504 Gateway Timeout?

Yes, and it is the single most common cause we find, particularly backup, import, security scanning, and related-posts plugins. Deactivating all plugins and reactivating them in groups of five normally identifies the culprit within 15 minutes.

Is a 504 the Same as a 502 Bad Gateway?

No. A 502 means the upstream process replied with something invalid or crashed outright, while a 504 means it never replied at all before the clock expired. A 502 often follows a PHP-FPM restart or segfault; a 504 follows a slow query or a stalled API call.

Will More RAM Fix the Problem?

More memory helps only when the stall comes from swapping or from too few PHP workers, which is perhaps a third of cases. If a single query takes 90 seconds, that query will still take 90 seconds on a bigger server.

Get Your WordPress Site off Timeout-Prone Hosting

If 504 errors keep returning after you have cleaned up plugins and queries, the platform underneath is the limiting factor. Talk to our team about a free migration and we will tune PHP workers, caching, and timeouts for your actual traffic pattern before the site goes live.