504 Gateway Timeout on WordPress: Why Your Pages Take Forever and Then Fail

The error that means your server ran out of patience

A 504 Gateway Timeout is different from a crash. Your server is running. PHP is running. Your database is running. Everything is alive and connected. But somewhere in the chain, a request is taking so long to process that the web server — Nginx, Apache, or a CDN like Cloudflare — gives up waiting and tells the visitor to go away.

The timeout threshold is configurable. Nginx defaults to 60 seconds. Cloudflare free plans timeout at 100 seconds. Your hosting provider may set it even lower. When PHP takes longer than this threshold to generate a response, the web server returns a 504 to the visitor. The PHP process might still be running in the background, chewing through whatever slow operation triggered the timeout. But the visitor is already gone.

The 504 is especially insidious because it often starts as a performance problem. Your site does not go from fast to 504 overnight. It slows down gradually. Response times creep up from 200 milliseconds to 2 seconds, then to 5 seconds, then to 15 seconds. Visitors notice the slowness but you do not, because you are testing from your office on a fast connection with your browser cache warm. Then one day, a traffic spike or a particularly heavy page load pushes response times past the timeout threshold. The 504 appears for the first time. And by then, the underlying problem has been building for weeks.

1. Slow PHP scripts that exceed the timeout

Every WordPress page requires PHP to execute code — loading the theme, running plugin hooks, querying the database, generating HTML. Most pages complete this in under a second. But some operations take much longer. A WooCommerce product page with 50 variations and no object cache. A page builder rendering a complex layout with nested queries. A plugin running an API call to a third-party service that is itself slow. A contact form plugin validating email addresses against a remote DNS lookup.

When any of these operations takes longer than the proxy timeout, visitors get a 504. The page was going to load eventually — maybe in 90 seconds — but the web server only waited 60. From the server's perspective, everything is fine. From the visitor's perspective, the site is broken.

How to fix it: Enable the PHP-FPM slow log by setting request_slowlog_timeout = 5s in your PHP-FPM pool configuration. This logs every request that takes longer than 5 seconds, including the exact PHP function that was running at that time. This tells you precisely which plugin, theme function, or database query is the bottleneck. Then optimise that specific code path — add caching, reduce the number of queries, or move the heavy operation to a background process using WordPress cron or Action Scheduler.

2. Long-running database queries

WordPress relies heavily on its database. Every page load triggers multiple queries — fetching post content, loading options, checking user permissions, running plugin queries. Most of these complete in milliseconds. But a single slow query can tie up a PHP worker for seconds or even minutes.

Common culprits include: the wp_options table with thousands of autoloaded rows (every page load queries every autoloaded option), the wp_postmeta table without proper indexes on large sites, WooCommerce order queries on stores with tens of thousands of orders, and search queries on sites without a proper search index. A query that takes 30 seconds leaves the PHP worker waiting for the database response the entire time. Stack a few of these together and every PHP worker is blocked, leading to 504 errors site-wide.

How to fix it: Enable the MySQL slow query log by adding slow_query_log = 1 and long_query_time = 2 to your MySQL configuration. This logs every query taking longer than 2 seconds. Use EXPLAIN on the slow queries to understand their execution plan. Common fixes include adding database indexes, cleaning up autoloaded options in wp_options, deleting post revisions and transients, and adding object caching with Redis or Memcached to eliminate repeated queries. Refer to the WordPress optimization documentation for database tuning guidance.

3. Proxy timeout configuration too low

Your web server has a timeout value that defines how long it will wait for PHP to respond. If this value is set too low for the work your site does, legitimate requests will trigger 504 errors even though they would complete successfully with a few more seconds.

This is common on Nginx setups where the default proxy_read_timeout or fastcgi_read_timeout is 60 seconds. Sixty seconds sounds generous — until your WooCommerce checkout processes a payment through a gateway that takes 45 seconds, and a slow database query adds another 20 seconds on top. The request needed 65 seconds. The timeout was 60. The customer sees a 504 instead of an order confirmation.

If you use Cloudflare, you face an additional timeout layer. Cloudflare free plan timeout is 100 seconds. If your origin server takes longer than 100 seconds to respond, Cloudflare returns its own 504 page — with Cloudflare branding and a different error code. You cannot increase this timeout on the free plan. Enterprise plans allow up to 6000 seconds, but that is not a fix — it is a band-aid for a performance problem.

How to fix it: For Nginx with fastcgi_pass (the most common WordPress configuration):

fastcgi_read_timeout 300;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;

For Nginx with proxy_pass (reverse proxy setups):

proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;

Increasing the timeout is a temporary fix. It prevents the 504 but does not solve the underlying performance problem. The real fix is always to make the slow request faster. A request that takes 90 seconds is a terrible user experience even if it does not 504.

4. Hosting resource limits and throttling

Shared hosting providers impose resource limits — CPU time, memory, number of processes, I/O throughput. When your site exceeds these limits, the hosting provider throttles your account. Throttling slows your PHP execution dramatically. A request that normally takes 2 seconds might take 30 seconds under throttling. If throttling pushes response times past the timeout threshold, visitors get 504 errors.

This is different from the 502 Bad Gateway where the hosting provider kills the process outright. With throttling, the process is still running — just painfully slowly. The server is not refusing connections. It is accepting them, starting to process them, and then timing out because it cannot finish in time.

Resource throttling often happens during specific events: a traffic spike from a social media mention, a bot crawling your site aggressively, a cron job running during peak hours, or a plugin performing a bulk operation like importing products or sending newsletters. The timing makes it feel random to you — everything was fine yesterday, but today certain pages return 504.

How to fix it: Check your hosting control panel for resource usage graphs. Look for CPU usage hitting 100% or memory approaching the limit. If you are consistently hitting resource caps, you have two options: optimise your site to use fewer resources (caching, fewer plugins, optimised queries) or upgrade your hosting plan. Moving from shared hosting to a VPS or managed WordPress host gives you dedicated resources that are not shared with other accounts. If traffic spikes are the trigger, add a CDN to serve static assets and page caching to reduce the number of requests that need PHP processing.

5. External API calls that block page rendering

Some WordPress plugins make external API calls during page rendering. A social sharing plugin fetching share counts from Facebook and Twitter. An analytics plugin loading data from a remote service. A currency converter plugin checking exchange rates. A weather widget querying a weather API. Each of these calls adds network latency to your page load time.

If the external API is slow or unresponsive, the PHP script blocks — waiting for a response from a server you do not control. If the API call has no timeout or a generous timeout (30 seconds), and multiple API calls are made per page, the total page generation time can easily exceed your proxy timeout. Your visitor gets a 504 because Facebook's share count API took 45 seconds to respond.

How to fix it: Identify plugins that make external API calls during page rendering. Set aggressive timeouts on all outbound HTTP requests — 5 seconds maximum. Cache API responses so you are not making the same call on every page load. Better yet, move external API calls to background processes using WordPress cron and store the results in a transient. The page loads instantly from the cached data. The fresh data is fetched in the background on a schedule.

6. PHP max_execution_time versus proxy timeout mismatch

PHP has its own execution time limit: max_execution_time, set in php.ini. The default is 30 seconds. This is separate from the web server's proxy timeout. If max_execution_time is set higher than the proxy timeout, PHP will happily continue processing a request that the web server has already given up on. The visitor saw a 504 sixty seconds ago. PHP is still running the script, consuming CPU and memory, generating a response that nobody will ever see.

The reverse is also problematic. If max_execution_time is set lower than the proxy timeout, PHP kills the script before the proxy times out. The visitor sees a 500 Internal Server Error or a white screen instead of a 504. Both are bad, but the error codes are different, which can make debugging confusing.

How to fix it: Align your timeout values. Set max_execution_time in php.ini to the same value as your proxy timeout — or slightly higher so that PHP can finish generating an error response before the proxy gives up. A common configuration: max_execution_time = 120, fastcgi_read_timeout = 120. But remember, if you regularly need more than 30 seconds to generate a page, you have a performance problem that timeouts cannot solve.

Why the 504 is a warning sign, not just an error

The 502 Bad Gateway is a crash. It happens suddenly. The 504 Gateway Timeout is different — it is the final symptom of a site that has been slowing down for days, weeks, or months. Response times do not jump from 200 milliseconds to 60 seconds overnight. They degrade gradually, and the 504 appears only when they cross the timeout threshold.

This means the 504 is actually an opportunity. If you track response times over time, you can see the degradation happening before it causes an outage. A site averaging 500ms that suddenly averages 3 seconds is already in trouble — even though it is still loading for visitors. If you catch it at 3 seconds, you can fix the problem before it hits 60 seconds and triggers a 504. If you wait for the 504, you are already in an outage.

How to detect 504 errors and performance degradation with Uptrue

Uptrue's HTTP monitoring catches 504 errors the moment they happen. But more importantly, it tracks response time trends so you can see your site slowing down before it reaches the timeout threshold.

Step 1: Set up an HTTP monitor to catch 504 status codes

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter your homepage URL
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Configure alerts — Slack, email, or Microsoft Teams

The moment your site returns a 504 instead of 200, Uptrue triggers an alert. Uptrue uses a two-confirmation check — if the first check fails, it retries from a different location before alerting. This eliminates false positives from momentary network issues while still catching real 504 errors within two minutes.

Step 2: Track response time trends to catch slowdowns early

Every HTTP check records the response time. Uptrue displays this as a trend over time in your dashboard. A healthy site shows a flat line around a consistent response time. A site heading towards a 504 shows a gradual upward trend — response times creeping higher week by week.

Check your response time trends weekly. If you see average response times increasing — from 400ms to 800ms to 1.5 seconds — investigate before it reaches your timeout threshold. The cause is usually a growing database, a newly installed plugin, or increasing traffic without corresponding infrastructure upgrades.

Step 3: Monitor your slowest pages individually

Not all pages are equally fast. Your homepage might load in 500ms while your WooCommerce shop page takes 4 seconds. The shop page will hit the timeout threshold long before the homepage does. Set up individual monitors for:

• Homepage — your baseline performance indicator
• WooCommerce shop and product pages — heavy database queries
• Checkout page — payment gateway API calls add latency
• Search results page — search queries are often the slowest
• Admin-heavy pages receiving traffic — dashboards, account pages
• Any page receiving paid traffic — slow pages waste ad spend

Step 4: Add keyword monitoring as a backup

1. Click Add Monitor again
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to "Gateway Timeout"
5. Set the check type to "Page must NOT contain"
6. Set the interval to 1 minute

Some CDN and caching configurations intercept the 504 and serve a custom error page with a 200 status code. The page often contains the text "Gateway Timeout" or "504." This keyword monitor catches those cases that slip past HTTP status code checking.

Step 5: Configure alerts for maximum speed

A 504 means visitors are waiting 60 seconds or more and then seeing an error. This is worse than a fast error like a 500 — the visitor wasted a full minute of their life before being told the site is broken. They will not try again.

• Slack — instant notification in a dedicated channel
• Microsoft Teams — immediate visibility for your team
• Email — written record as a backup alert
• Webhook — pipe alerts into PagerDuty, Opsgenie, or your incident management system

Preventing 504 errors before they happen

Add page caching

Page caching serves pre-generated HTML files, bypassing PHP and the database entirely. A cached page responds in milliseconds regardless of how complex the underlying WordPress page is. Install a caching plugin like WP Super Cache or W3 Total Cache. If your host offers built-in caching (Kinsta, WP Engine, Cloudways), enable it. Page caching alone eliminates the vast majority of 504 errors on WordPress sites.

Add object caching with Redis

Object caching stores database query results in memory. WordPress does not have to query the database on every page load for data that rarely changes — options, user meta, transients. This reduces both PHP execution time and database load. Most managed WordPress hosts include Redis. On a VPS, install Redis and the Redis Object Cache plugin.

Optimise your database

Delete post revisions, expired transients, spam comments, and trashed posts. Clean up the wp_options table — remove rows from plugins you have already uninstalled. Check that autoloadis set to "no" for large options that do not need to load on every page. Add indexes to custom tables created by plugins. A lean database responds faster and uses less memory.

Audit your plugins

Every active plugin adds PHP execution time to every page load. Some plugins are well-optimised and add microseconds. Others add seconds. Use the Query Monitor plugin in development to identify which plugins are adding the most database queries and the most execution time. Deactivate or replace plugins that are disproportionately slow. The fewer plugins you run, the faster your site loads and the further you are from the timeout threshold.

Use a CDN

A CDN serves static assets (images, CSS, JavaScript, fonts) from edge servers close to your visitors. This reduces the number of requests that reach your origin server, leaving more capacity for the dynamic PHP requests that actually need processing. Cloudflare, Bunny CDN, and KeyCDN are popular options that work well with WordPress.

Stop waiting for the 504 to find you

A 504 Gateway Timeout is the last stage of a performance problem that has been building for a long time. By the time your visitors see it, your response times have been degrading for days or weeks. The visitors who waited 8 seconds and gave up before the timeout never showed up in your error logs — they just left.

Uptrue checks your site every 60 seconds and records the response time on every check. The moment a 504 is returned, you know. But more importantly, you can see the trend. You can see your site slowing down from 400ms to 2 seconds to 8 seconds — and you can fix it before it reaches the 60-second timeout that triggers the error.

Frequently asked questions