504 Gateway Timeout: What It Means and How to Fix It

A 504 Gateway Timeout means a proxy or gateway, usually Nginx, a load balancer, or a CDN, forwarded your request to an upstream server and gave up waiting because no response arrived in time. The upstream is not refusing the connection and it is not returning garbage, it is simply too slow. That distinction matters: a 502 says the backend answered badly, a 504 says it did not answer at all within the timeout. Almost every 504 traces to one of five things: a slow database query, a slow third party API call, an overloaded worker pool, a timeout set lower than the work actually takes, or a network path that stalls between the proxy and the app.

What does 504 Gateway Timeout mean?

HTTP 504 belongs to the 5xx family, which means the failure is on the server side, not in the visitor's browser. The specific meaning is defined by the request chain. A visitor hits a gateway. That gateway is not the machine that generates the page, so it passes the request to an upstream: PHP-FPM, a Node process, a Python app server, another load balancer. It then waits a fixed number of seconds. If the upstream has not produced a response by then, the gateway stops waiting, closes the transaction, and returns 504 to the visitor.

The important consequence is that the timeout number is a configuration choice, not a law of physics. A request taking 45 seconds succeeds behind a 60 second timeout and fails behind a 30 second one. So a 504 always has two halves: something is slow, and something else is unwilling to wait that long. You can fix either half, but only one of those fixes is durable.

What causes a 504 Gateway Timeout error?

Five causes cover the overwhelming majority.

A quick diagnostic that separates them: note how long the browser waits before the error appears. If it is consistently the same number, say exactly 60 seconds, you are hitting a configured timeout and the app is still grinding away behind it. If the delay varies, you are dealing with load or an unpredictable dependency.

How do I fix a 504 Gateway Timeout in Nginx?

Read the error log before touching any config. Run tail -50 /var/log/nginx/error.log and look for upstream timed out (110: Connection timed out) while reading response header from upstream. That line names the upstream that stalled and the request that triggered it, which is most of the diagnosis.

Nginx has three timeouts that matter and they apply at different stages:

• proxy_connect_timeout, how long to wait to establish the connection. If this one fires, the upstream is unreachable or saturated, not slow.
• proxy_read_timeout, how long to wait between successive reads from the upstream. This is the one that produces most 504s, and it defaults to 60 seconds.
• proxy_send_timeout, how long to wait while sending the request body upstream. This matters for large uploads.

If you use PHP-FPM through fastcgi_pass rather than proxy_pass, the equivalent directive is fastcgi_read_timeout, and raising the Nginx side alone will not help unless PHP agrees to run that long. PHP-FPM enforces its own ceiling with request_terminate_timeout, and PHP itself with max_execution_time. All three have to allow the duration or the shortest one wins.

Raising a timeout is triage, not a fix. It converts a fast failure into a slow success while the underlying request still ties up a worker for a minute, which is exactly how one slow endpoint takes down an entire site under load. Use the higher limit to buy breathing room, then go and make the request fast. If the slow path is an unindexed query or an N+1 in your ORM, that is a code change, and it is the sort of narrow, well-defined refactor an AI coding agent can plan and patch faster than you can bisect it by hand.

What is the difference between a 502 and a 504 error?

Both are gateway errors and both mean the backend failed, but they fail differently and the fixes diverge.

In practice they often alternate on the same incident. A backend that gets slow enough starts timing out (504), workers back up, the process gets killed or stops accepting connections, and the same URL begins returning 502 instead. If you see both codes in the same window, treat it as one capacity problem rather than two bugs. Our walkthrough of the 502 Bad Gateway error and its six causes covers the other half of that pattern.

What does a 504 from Cloudflare or a load balancer mean?

Managed layers add their own timeouts and their own error codes, and mixing them up wastes an hour.

Cloudflare returns error 524, not 504, when its own connection to your origin exceeds its timeout, which is 100 seconds on the standard plans. If Cloudflare shows you a genuine 504, it usually means your origin itself returned 504, so the problem is inside your infrastructure and Cloudflare is faithfully passing it along. The quickest way to confirm is to request the origin IP directly with a Host header and see whether the error follows you.

An AWS Application Load Balancer returns 504 when the target does not respond within the idle timeout, 60 seconds by default. The same applies to most managed proxies. If your app legitimately needs longer, raising the balancer timeout without raising the timeouts on every hop behind it just moves the failure one layer down.

How do I fix a 504 error in WordPress?

WordPress 504s are usually one of four things, and the order below is roughly the order of likelihood. A plugin doing outbound HTTP on every page load, which stalls when the remote service is slow. WP-Cron firing on a request when the site is busy, since by default it runs on visitor traffic rather than a real cron job. An admin action such as a bulk import or a large backup exceeding the request timeout. Or a shared host applying a much lower timeout than you expect.

Start by disabling plugins in halves until the slow endpoint gets fast, since that isolates the cause faster than reading code. Then move WP-Cron to a real system cron by setting DISABLE_WP_CRON to true and scheduling wp-cron.php yourself, which also makes scheduled jobs reliable rather than dependent on someone visiting the site. Long-running admin jobs belong in WP-CLI, not in a web request. Setting up monitoring for a WordPress site catches the pattern before customers report it.

Is a 504 error my fault or the website's?

If you are a visitor, it is not your fault and there is very little you can do. A 504 is generated server-side, so clearing your cache, switching browsers, or changing DNS will not resolve a real one. Reloading occasionally works, but only because the timeout was caused by transient load that has since cleared. If the error persists across devices and networks, the site is genuinely broken and only its operators can fix it.

If you are the operator, it is yours, including when the slow dependency belongs to someone else. A third party API that hangs for 90 seconds is their availability problem but your outage, which is why every outbound call in your codebase should carry an explicit timeout well below your proxy timeout. Failing fast with a degraded response beats holding a worker hostage.

Does a 504 error affect SEO?

A short burst does no lasting damage. Googlebot treats 5xx responses as temporary, backs off its crawl rate, and retries, so an isolated incident costs you nothing meaningful. Sustained 504s are a different matter: prolonged server errors slow crawling, delay indexing of new content, and, if a URL keeps failing for long enough, can lead to it being dropped from the index. The practical rule is that hours matter and minutes do not, which is also roughly how your customers experience it.

How to catch 504s before your customers do

The 504 that hurts is rarely the one that takes the whole site down, because that gets noticed in minutes. It is the report endpoint that times out for the 3 percent of accounts with enough data to trip the limit, or the checkout step that fails only during the evening peak. Manual spot checks never reproduce it, and the affected customers usually leave rather than file a ticket.

Continuous external checks are what surface that pattern. Point a monitor at the specific slow endpoints rather than just the homepage, since a fast marketing page tells you nothing about a heavy dashboard query. Set the check to treat any 5xx as a failure, and watch response time trends as well as pass or fail, because latency creeping from 2 seconds to 20 is the early warning that a 504 is coming. Checking from several regions separates a genuinely slow application from a single bad network path. Our breakdown of which HTTP status codes should trigger an alert covers where to set those thresholds.

If you have committed to an availability target in a customer contract, timeouts count against it exactly like a hard outage does, and 43 minutes is the entire monthly budget at 99.9 percent. Tracking that properly needs recorded, timestamped downtime rather than an impression of how the month went, which is what SLA monitoring with a measured uptime percentage is for.

The short version

A 504 Gateway Timeout means the proxy waited and the application never answered. Read the proxy error log first, because it names the stalled upstream. Note whether the delay is a consistent number of seconds, which points at a configured timeout, or variable, which points at load. Raise the timeout only to buy time, then fix the slow query, set explicit timeouts on outbound calls, and give the worker pool headroom for peak rather than average traffic. Then put continuous checks on the slow endpoints, because the 504 worth catching is the one only some of your customers ever see.