504 Gateway Timeout
A server acting as a gateway waited too long for a response from another server and gave up. A 504 is almost always a problem on the website's side, not your device or connection.
Updated September 2026 · 4 min read
-
Written by
Andrian Valeanu
Founder of Pulsetic
Andrian Valeanu founded Pulsetic. Before that, Designmodo. The 15-plus years in between went into web products, design tools and monitoring software that teams around the world run on.
-
Reviewed by
Ionut Caval
Technical reviewer
Ionut Caval reads every one of these guides before it goes out. Web servers, networking and uptime monitoring are his day job, so the causes and fixes here get checked against how things actually behave in production.
The short version: Reload after a minute before anything else: a 504 is almost always temporary and lives on the website's side, not your device. It means a gateway or proxy gave up waiting on a slow or overloaded upstream server. Run the website yourself? Speed up that back end or raise the gateway timeout instead of papering over the delay.
Key takeaways
- A gateway or proxy reached an upstream server but the answer never arrived in time, so it stopped waiting. RFC 9110 puts it plainly: the server did not get a timely response from an inbound server it needed to finish the request.
- This is the website's problem, not yours. As a visitor you have nothing to fix. Wait a minute and reload.
- 502 and 504 split cleanly. A 502 means the upstream replied with garbage. A 504 means it never replied in time. Compare those with a 503 (the server refusing on purpose) and a 500 (the application crashing).
- Behind Cloudflare, an origin that times out returns 524, which fires at 125s, not 504. So a plain 504 coming through Cloudflare usually traces to a second proxy or the origin's own gateway.
- For owners the order matters: fix the slow upstream first, then reach for a longer gateway timeout (nginx proxy_read_timeout, Apache ProxyTimeout) as a stopgap. Longer timeouts never cure slow code.
- Error type
- HTTP 5xx server error
- Whose side
- Almost always the website
- Fix difficulty
- Moderate (website owner)
- Common cause
- Upstream server too slow or overloaded
How did you find out this time?
Pulsetic is website uptime monitoring. It checks your URL from outside your network as often as every 30 seconds, confirms any failure from another region, then emails you.
10 monitors free, email alerts on failure and recovery. No credit card.
What does 504 Gateway Timeout mean?
A 504 Gateway Timeout is an HTTP status code that shows up when one server, acting as a gateway or proxy, does not get a response in time from another server it depends on. The server you reached is online; it simply gave up waiting on a back-end server to answer.
Because the timeout happens between two servers, a 504 is almost always a problem with the website's infrastructure, not your browser, device, or internet connection. As a visitor, there is little to do beyond waiting and reloading.
- 504
- HTTP status code
- ~60s
- Default Nginx proxy timeout
- 125s
- Cloudflare origin timeout (Error 524)
How the 504 Gateway Timeout error appears
The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:
504
Gateway Timeout
The server didn't respond in time.
504 Gateway TimeoutHTTP Error 504Gateway Timeout (504)nginx: 504 Gateway Time-outCloudflare: 504 Gateway time-out (Error 504)This page isn't working / took too long to respond
504 vs 502, 503 and 500
All four are 5xx server-side errors, but each points to a different failure between the gateway, the origin, and the application.
| Code | What it means | Who fixes it |
|---|---|---|
| 500 Internal Server Error | The application itself hit an unhandled error or crash while processing the request, with no more specific status to report. | Website owner: check application logs, recent code, and server config |
| 502 Bad Gateway | A gateway or proxy reached the upstream server but got an invalid or empty response back. | Website owner: fix or restart the upstream app the proxy talks to |
| 503 Service Unavailable | The server is reachable but is refusing the request right now because it is overloaded, restarting, or in maintenance. | Website owner: ease load, finish the deploy, or wait out maintenance |
| 504 Gateway Timeout | A gateway or proxy got no response in time from the upstream server it depends on. | Website owner: speed up the slow upstream or raise the gateway timeout |
Gateway and upstream timeout directives
A 504 is almost always one of these timers expiring before the upstream answered, so this is where owners look first.
| Directive | Default | What it controls |
|---|---|---|
proxy_read_timeout (nginx) | 60s | Time nginx waits between reads from a proxied upstream before returning 504 |
proxy_connect_timeout (nginx) | 60s | Time nginx waits to establish the connection to the upstream |
fastcgi_read_timeout (nginx) | 60s | Time nginx waits for a response from a FastCGI backend such as PHP-FPM |
ProxyTimeout (Apache) | Falls back to Timeout (60s) | Time mod_proxy waits for the backend; inherits the global Timeout if unset |
request_terminate_timeout (PHP-FPM) | 0 (off) | Hard kill for a PHP worker; should match the nginx FastCGI timeout |
| 524 trigger (Cloudflare) | 125s (proxy read timeout) | Cloudflare's own origin timeout, returned as 524 not 504 |
What causes 504 Gateway Timeout?
- The origin (upstream) server is overloaded and answering too slowly, which often happens during a traffic spike.
- A slow database query or a long-running request runs past the time the gateway is willing to wait.
- The origin server has crashed or gone offline, so the gateway gets nothing back at all.
- Reverse proxy or load balancer timeouts (Nginx
proxy_read_timeout, ApacheProxyTimeout, HAProxy, and so on) are set tighter than the request actually needs. - A CDN or proxy in front of the website, such as Cloudflare or Fastly, cannot reach the origin inside its timeout window.
- Network or firewall trouble between the gateway and the upstream server delays or drops the connection.
How to find the cause fast
- Reload once after a minute, then open the website on another network or through Is Website Down? to confirm it is failing for everyone, not just you.
- Owners: read the proxy and origin logs (for example
tail -f /var/log/nginx/error.log) and look for upstream timeout entries. That tells you whether the proxy or the back end is the one timing out. - Time the request with
curl -w "%{time_starttransfer}" -o /dev/null -s https://yourdomain.com. A slow upstream and an unreachable one look very different here. - Got a CDN or proxy out front? Hit the origin directly (or pause Cloudflare) to learn whether the timeout sits at the edge or the origin.
How 504 Gateway Timeout looks from the outside
Seen from outside, a 504 is an answered request, not a dead one. An external monitor logs a clean HTTP 504 with a fairly normal response time, and that alone tells you the edge is up while an upstream server is the culprit, well before you open a log. These failures tend to be spiky and short-lived in our experience, so a single failed check is usually just noise. The same 504 repeating across several locations for a few minutes is the signal worth acting on.
To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.
How to fix 504 Gateway Timeout
If you are a visitor
- Give it a minute, then reload the page. A 504 is often temporary and clears once the server catches up.
- Try the website in a different browser or a private window to rule out a cached error page.
- See whether it is down for everyone with Is Website Down? If it is down for all, the issue is on their end and waiting is your only option.
- Only look at your own connection if other websites are failing too. A 504 almost never points back at your network.
If you run the website
- Check the origin server's health and logs for crashes, out-of-memory events, or processes stuck at 100% CPU.
- Hunt for slow database queries or long-running application requests. A single slow query can hold a worker long enough to trip the timeout.
- Confirm your reverse proxy or load balancer can actually reach the upstream app server, and that the app is listening on the port it should be.
- When the work legitimately runs long, raise the gateway timeout (Nginx
proxy_read_timeoutandproxy_send_timeout, ApacheProxyTimeout, HAProxytimeout server). This is a stopgap, not a cure for slow code. - On Cloudflare or another proxy, verify it can reach your origin. Keep in mind Cloudflare's own origin timeout is Error 524; a 504 through Cloudflare usually means a gateway between it and your origin, or the origin itself, handed back a 504.
- When the timeouts track your traffic peaks, add capacity or scale out so the origin can keep pace.
Still not fixed? Next steps
- When a longer gateway timeout only pushes the 504 back a few seconds, go after the upstream itself. One slow database query or external API call can hold a worker hostage past every timer you set.
- Hit the origin directly. If it answers fine but visitors still see 504, the fault lives in the proxy, load balancer, or CDN config between you and them, not in the application.
- Do the 504s track your traffic peaks? Then the upstream is saturated. Add workers or scale out instead of just stretching timeouts.
- On a managed stack where none of this applies, hand your host the affected URL plus exact timestamps. That lets them inspect the gateway and origin from their side.
Code & configuration
Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.
Raise the gateway timeout (Nginx)
location / {
proxy_read_timeout 120s;
proxy_connect_timeout 120s;
proxy_send_timeout 120s;
fastcgi_read_timeout 120s;
}
Apache and PHP equivalents
# Apache (httpd.conf)
Timeout 120
ProxyTimeout 120
# PHP (php.ini): for long-running scripts
max_execution_time = 120
How to prevent 504 Gateway Timeout
A 504 tends to come and go inside a few minutes, which is exactly why it slips by until a customer flags it. Pulsetic checks your website from multiple locations as often as every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, and more the instant it starts returning 504s or stops responding. It will not name the slow query for you, but it tells you fast that something is wrong, and when it recovers, so you can move before your visitors do.
Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.
Sources and further reading
The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.
Frequently asked questions
-
Is a 504 Gateway Timeout my fault or the website's?
Almost always the website's. A 504 means two of the website's own servers could not reach each other in time. Nothing on your device needs fixing beyond a reload, and if the website is down for everyone, you can only wait for the owner to sort it out.
-
How long does a 504 Gateway Timeout last?
It depends on what caused it. A 504 from a quick traffic spike can clear in seconds or minutes once the load eases. One caused by a crashed server or a botched deployment hangs around until someone fixes it. Past a few minutes, the website owner needs to step in.
-
What is the difference between a 504 and a 502 Bad Gateway?
Both involve a gateway and an upstream server. A 502 Bad Gateway means the gateway got an invalid or empty response from the upstream. A 504 Gateway Timeout means it got no response in time, full stop. Put simply: a 502 means the answer was broken, a 504 means the answer never came.
-
Can I fix a 504 by refreshing the page?
Sometimes. If the upstream server was only briefly overloaded, a reload a minute later often does the trick. But if refreshing keeps returning a 504, the problem is still live on the server side and reloading will not get you anywhere.
-
Does a 504 error hurt SEO?
A brief, one-off 504 is unlikely to dent your rankings, since crawlers just come back and retry the URL. The trouble starts when 504s pile up or drag on: repeated timeouts can slow how often your pages get crawled, and a key page that keeps timing out may drop out of results until it answers again. The safest move is to return a fast, correct status instead of hanging, and to fix the slow upstream quickly.
-
Why does WordPress return a 504, and can a plugin cause it?
It can. A plugin or theme triggers a 504 whenever it kicks off a slow task that outlives the gateway timeout: a heavy import, a backup, an external API call, an expensive database query. Long
wp-cronjobs and bloated page builders show up here all the time. To pin it down, deactivate plugins one by one or drop back to a default theme, and watchwp-content/debug.logfor the request that stalls. -
Why is Cloudflare showing a 504 when my server seems fine?
Cloudflare's own origin timeout is Error 524, not 504. So a 504 coming through Cloudflare usually means a gateway between Cloudflare and your origin (a second proxy, a load balancer, or the origin's own gateway) timed out, or your origin handed back a 504 that Cloudflare passed along. Either way the fix lives at the origin: test by pausing Cloudflare or requesting the origin directly, and if it still fails, repair the slow back end sitting behind it.
-
How do I fix a 504 specifically on nginx?
On nginx the 504 almost always traces to a directive that expired before the upstream answered. Proxying to an app server? Raise
proxy_read_timeoutandproxy_send_timeout. Talking to PHP-FPM? Raisefastcgi_read_timeoutand the matchingrequest_terminate_timeoutin the FPM pool. Reload withnginx -t && systemctl reload nginx, and remember a longer timeout only buys time while you fix the slow back end. -
What is the difference between a 504 and an ERR_CONNECTION_TIMED_OUT?
They read alike but fail at different layers. A 504 is an HTTP response that actually came back: a gateway reached the upstream, waited, and reported the timeout, which tells you the edge is up. ERR_CONNECTION_TIMED_OUT is the browser failing to open any connection at all, usually a network, DNS, or firewall snag, and no HTTP status is ever returned. So a 504 points at the website's back end, while a connection timeout could sit on either side.
-
Can a load balancer cause a 504 even when every server is healthy?
It can. An AWS ALB, HAProxy, or anything similar carries its own idle and response timeouts (the ALB idle timeout, for instance, defaults to 60 seconds). A legitimate long request that outruns that window gets a 504 from the balancer even while the backend keeps working. The fix is to line up the balancer timeout, the proxy timeout, and the application's execution limit so your slowest valid request fits inside all three.
-
Should I just raise the timeout to make a 504 go away?
Only to buy time. Stretching proxy_read_timeout, ProxyTimeout, or max_execution_time keeps the gateway from quitting early, but it does nothing to the work itself, so visitors just wait longer for a page that is still slow. Use the higher timeout as breathing room while you hunt the real cause: a slow query, an unindexed table, a heavy external API call, a saturated worker pool. And if a request genuinely needs minutes, push it to a background job and return right away.
-
Which timeout actually triggers the 504, the gateway or PHP?
Whichever is shortest wins. If nginx's proxy_read_timeout or fastcgi_read_timeout (60s by default) sits below PHP's max_execution_time, nginx fires the 504 before PHP finishes and the PHP script keeps running orphaned. Flip it, and PHP gets killed first, at which point the proxy tends to show a 502 instead. The logs settle the question: an nginx upstream timeout means the gateway timer, a PHP fatal about maximum execution time means the application limit. Align the two and they will fail predictably.
-
Why does a 504 appear at the same time every day?
A 504 on a clockwork schedule almost always rides on top of a heavy recurring job: a nightly backup, a cron task, a report build, a cache rebuild. Whatever it is, it pins the database or the workers for a few minutes. During that window normal requests pile up past the gateway timeout and come back 504, then everything clears the moment the job finishes. Match your cron and scheduled tasks against the timestamps; moving the heavy job off-peak or throttling it usually kills the daily spike.
-
If Cloudflare uses Error 524 for origin timeouts, when would I ever see a real 504 behind Cloudflare?
Cloudflare answers with 524 when your origin stays silent for roughly 125 seconds, so a plain 504 served through Cloudflare nearly always starts further down: a second proxy, a load balancer, or the origin's own gateway timed out and Cloudflare just passed that 504 along. Easiest test is to request the origin IP directly and skip Cloudflare entirely. From the outside, an external check that records the exact status code (524 versus 504) and the response time already shows you whether the edge or something behind it gave up, before you touch a log. Pulsetic checks from 15+ locations every 30 seconds and logs the precise code returned, which is what lets you tell a Cloudflare-level timeout from an origin-level one at a glance.
Trusted by teams at companies around the world
-
Catch the next outage before your visitors do.
2-minute setup · Cancel any time
-
No credit card needed