A page spins for a full minute, then dies with 504 Gateway Timeout.
Short answer: your web server or CDN waited on the app that builds the page, and that app took too long. On WordPress that’s usually a slow database query, a heavy plugin task or an outside API that hangs. Find the slow request first. Raising the timeout comes last, if at all.
We timed Nginx in a lab to see exactly when a 504 error fires, and which requests it quietly retries.
What does 504 Gateway Timeout mean?
A 504 Gateway Timeout means a gateway or proxy didn’t get a timely response from the server behind it. That’s the definition in RFC 9110, the HTTP standard.
Two servers are involved, and your browser is neither of them.
- The gateway receives your request: Nginx, a load balancer, a hosting proxy or a CDN.
- The upstream does the actual work. On WordPress that’s PHP-FPM; behind a CDN it’s your own origin server.
- The 504 is the gateway’s stopwatch running out before the upstream sent back the start of a reply.
That last detail matters. The upstream isn’t broken or refusing connections. It’s busy, stuck or waiting on something else. That’s the line between a 504 and a 502 Bad Gateway, where the reply is broken or never comes at all.
Seeing a 504 on someone else’s site? Here’s what you can do
If it isn’t your site, the fault is almost certainly on their server. You have three moves.
- Wait a minute, then reload once. A 504 often clears when a traffic spike or a backup job ends. Don’t hammer refresh, because every reload adds another slow request to the queue.
- Don’t resubmit a form or payment blindly. The server may have finished your order after the gateway gave up. Check your email or account before you try again.
- Turn off your VPN or proxy. A slow exit server is a gateway too, and it can time out on its own. We walk through that one in our proxy errors fix list.
Clearing your cache, cookies or DNS won’t fix a real 504. Nothing on your device made the server slow.
We timed Nginx to see exactly when a 504 fires
In November 2026 we put Nginx 1.26.3 in front of a tiny test app on our Linux box. The app could be told to sleep before replying, so we could time every request to the hundredth of a second.
No live WordPress site was harmed. The timers and log messages, though, are exactly what a production Nginx uses.
| What we tested | Result | Time to answer |
|---|---|---|
| App takes 15 s, Nginx default settings | 200, page loads | 15 s |
| App takes 65 s, Nginx default settings | 504 Gateway Time-out | 60.0 s |
| App takes 15 s, timeout set to 10 s | 504 Gateway Time-out | 10.0 s |
| App takes 15 s, timeout raised to 30 s | 200, page loads | 15 s |
| Two app servers, one stuck, GET request | 200 from the healthy server | 3.0 s |
| Two app servers, one stuck, POST request | 504 Gateway Time-out | 3.0 s |
Three things stood out. First, the default limit is exactly 60 seconds: our 65-second request failed at 60.03 s. That matches the proxy_read_timeout 60s default in the Nginx docs.
Second, a 504 is slow by nature. Our broken-app tests for the 502 guide failed in under 2 milliseconds. Every 504 here took the full timeout, so a visitor stares at a spinner first.
Third, the last two rows. When we added a backup app server, Nginx retried the stuck GET on the healthy one and the visitor got the page, just 3 seconds late. The POST got a 504 instead. Since version 1.9.13, Nginx won’t resend a POST to another server, because it can’t know whether the first one already saved the order.
Every timeout left this line in the error log:
[error] upstream timed out (110: Connection timed out) while reading
response header from upstream, client: 127.0.0.1,
request: "GET /short/?sleep=15 HTTP/1.1", upstream: "http://127.0.0.1:9101/?sleep=15"The request field is the useful part. It names the exact URL that was too slow, which tells you where to dig.
How to fix a 504 Gateway Timeout on your own site
Start by finding which requests time out, then work out why they’re slow. Search the log for the timeout message:
sudo grep "upstream timed out" /var/log/nginx/error.log | tail -n 20
# count which URLs time out most often:
sudo grep -o 'request: "[A-Z]* [^ ]*' /var/log/nginx/error.log | sort | uniq -c | sort -rn | headThen follow the pattern you see:
Fix a 504 from the slow request outward
Work through these in order. Most 504s are solved by step 2 or 3.
-
Step 1 of 5
Every page times out: check the server is keeping up
Run top or htop. If CPU is pinned or memory is full, the server is overloaded. Look for a runaway process, a backup running at peak hours or a traffic spike from bots.
-
Step 2 of 5
One URL times out: profile that request
On WordPress, the free Query Monitor plugin shows slow database queries and outside HTTP calls for a page. A plugin calling a dead remote API can hold a page for a minute.
-
Step 3 of 5
Only admin tasks time out: move the work out of the request
Imports, exports, bulk edits and report builders shouldn’t run inside one web request. Use WP-CLI, a background queue or smaller batches.
-
Step 4 of 5
The database is the bottleneck: fix the query, not the timer
Turn on the MySQL slow query log, then add the missing index or clean up bloated tables such as wp_options autoload data and old revisions.
-
Step 5 of 5
The task is slow by design: raise the limit for that path only
Set proxy_read_timeout (or fastcgi_read_timeout for PHP) higher in a location block for that one URL, and raise PHP’s max_execution_time to match. Leave the rest of the site at 60 seconds.
Raising the limit worked in our lab. The same 15-second request that failed at a 10-second timeout loaded fine at 30 seconds. But the visitor still waited 15 seconds for a page, and that’s the real problem.
# example: a longer limit for admin-ajax only, where the export runs
location /wp-admin/admin-ajax.php {
fastcgi_read_timeout 180s;
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}Watch out: the timeouts have to line up. If PHP’s max_execution_time is lower than Nginx’s limit, PHP kills the script first and you get a PHP error instead of a 504. If Cloudflare sits in front, its own limit caps everything behind it.
Behind Cloudflare? A 504 and a 524 mean different things
Sites behind Cloudflare can show two timeout codes, and they point to different layers.
- A Cloudflare-branded 504 page means your origin server sent the 504. Your own Nginx or host proxy gave up on PHP. Fix it on the server, as above.
- A 524 error means Cloudflare reached your server but got no reply within its Proxy Read Timeout, which is 125 seconds by default. Your origin is even slower than that.
Cloudflare’s advice for jobs that genuinely run longer is to move them to a subdomain that isn’t proxied, or to have the page poll for progress instead of waiting on one long request. Only Enterprise plans can raise the 524 limit.
Why WordPress sites hit 504s
Every uncached WordPress page runs PHP and a stack of database queries before Nginx gets a single byte back. Anything that stretches that work past 60 seconds becomes a 504.
The usual suspects are WooCommerce reports on a big order table, a backup or import plugin running inside a web request, a slow search query and plugins that call outside services without a sensible timeout. WP-Cron adds to it, because scheduled tasks fire during normal page loads unless you move them to a real system cron.
Caching takes most visitors off that path entirely. A cached page never reaches PHP, so it can’t time out. That’s why a caching plugin like WP Rocket cuts 504s on busy sites, and our guide to speeding up WordPress shows the other fixes we measured on our own blog.
504 vs 502 vs 503: which one are you looking at?
| Code | What happened | Where to look first |
|---|---|---|
| 502 Bad Gateway | The upstream refused, crashed or sent a broken reply | Error log, then PHP-FPM or app status |
| 503 Service Unavailable | The server says it can’t take requests right now | Maintenance mode, rate limits, full worker pools |
| 504 Gateway Timeout | The upstream was too slow to start its reply | Slow queries, long tasks, outside API calls |
| 524 (Cloudflare only) | Your origin took longer than Cloudflare’s 125-second limit | The same slow request, on your origin |
The timing is a good tell. A 502 usually appears instantly. A 504 appears after a suspiciously round wait, such as 30 or 60 seconds, because that’s someone’s timeout setting.
When 504s keep coming back, look at your hosting
A 504 once a month on a huge export is normal. A 504 every busy afternoon is a capacity problem.
On shared hosting you can’t change Nginx timeouts or the PHP worker count, and a neighbour’s traffic can slow your database. Ask your host for the exact timeout values and how many PHP workers your plan gets. Our guide to how web hosting works explains where those limits sit.
If you’ve already cached and optimised, more resources are the honest fix. Moving up to Hostinger‘s higher tiers or a managed WordPress host such as Pressable buys headroom, plus support staff who can see the logs you can’t. Our managed vs shared WordPress hosting comparison helps you decide when that upgrade pays off.
Want full control of every timeout? A plan from our VPS hosting roundup lets you set them yourself.
Disclosure: Hostinger, Pressable and WP Rocket links on this page are affiliate links. If you sign up through one, we may earn a commission, and your price stays the same.
Frequently Asked Questions
Does a 504 Gateway Timeout hurt SEO?
A brief one doesn’t. Google treats 5xx errors as temporary and slows its crawling while they last. If the same URLs keep returning server errors for days, Google can drop them from its index, so fix repeat 504s quickly.
How long does a 504 Gateway Timeout last?
One caused by a traffic spike or a backup job usually clears within minutes. One caused by a slow query or a hanging plugin returns on every request to that page until someone fixes the code or the server.
What is the default Nginx timeout before a 504?
Sixty seconds. Nginx’s proxy_read_timeout and fastcgi_read_timeout both default to 60s, and our lab request failed at 60.03 seconds. The timer counts the gap between reads from the upstream, not the whole response.
Can a WordPress plugin cause a 504?
Yes. A plugin that runs a heavy query or calls a slow outside API can hold PHP past the gateway’s limit. Disable plugins one at a time, or use Query Monitor to see which one adds the time.
Did my form or order go through after a 504?
Possibly. The gateway stops waiting, but the app behind it may keep running and finish the job. Check your email, account or admin panel before you submit again, so you don’t pay or post twice.
Is a 504 error caused by my internet connection?
Almost never. A real 504 comes from a server that waited on another server. The exception is a VPN, proxy or office gateway you route through, which can time out on its own. Try without it.
Should I just raise the timeout to fix a 504?
Only for a task that’s slow by design, like a big export, and only on that path. For normal pages, a longer limit means visitors wait longer before failing. Fix the slow query or move the task into the background instead.
The bottom line
A 504 Gateway Timeout means the gateway waited and the app behind it was too slow. Visitors can only wait, avoid double-submitting and drop their VPN.
Site owners should grep the Nginx error log for upstream timed out, find the slow URL and fix why it’s slow: the query, the plugin, the outside API or the long task. Raise a timeout only for a job that truly needs it, and if 504s still come back at busy times, your hosting plan has run out of room.
Next step: run the grep command above today, even if your site seems fine. Any URL already near the limit will show up there first.
