504 Gateway Timeout: Causes & Fixes

By Marcus Feld, Infrastructure Editor

What a 504 Gateway Timeout Error Means

A 504 Gateway Timeout error means a server acting as a gateway or proxy sent a request to an upstream server and didn’t get a response within the allowed time. The proxy isn’t broken. It’s reporting that whatever sits behind it was too slow to answer, so it gave up waiting. This is closely related to a 502 Bad Gateway error, since both are failures at the handoff between two servers. The difference is that a 502 means a bad or invalid response came back, while a 504 means nothing came back in time.

That single word, “slow”, changes how you fix it. A 500 or 502 often means something is broken and needs restarting or repairing. A 504 usually means something is working but taking too long, so the job is to find out what is slow and why. Restarting services may give brief relief, but it rarely cures a slow database query or a hanging external call.

Timeouts are also set by people. Every gateway has a limit, commonly measured in tens of seconds, and different layers (your CDN, your web server, your PHP settings) can each have their own. The 504 you see comes from whichever layer gave up first, and that detail is a useful clue.

Is It the Server, the Application or the Network?

• Application layer (most likely). A slow database query, a long running script or an external API call that hangs. The code is doing its job, only too slowly.
• Server layer. The origin is overloaded, so even ordinary requests queue up and cross the timeout line.
• Configuration layer. A timeout set too tight on the proxy, CDN or load balancer cuts off requests that would have finished.
• Network layer. Congestion or routing trouble between the proxy and the origin, more relevant in multi-region or CDN fronted setups.

The clearest diagnostic question is scope. If one page or one action times out while the rest of the site is fine, you’re looking at a slow specific operation. If everything is slow or failing, you’re looking at overload or a network issue.

Common Causes of a 504 Gateway Timeout Error, Ranked

This is a practical ordering from typical dynamic sites such as WordPress and WooCommerce. It is experience-based, not a measured statistic.

Slow or Unoptimised Database Queries

A query that takes too long to return holds the request open until the gateway gives up. Missing indexes, huge tables and plugins that run heavy queries on every page view are classic sources. A query that was fast at launch can crawl once a table grows.

Long Running Scripts or Processes

Large exports, bulk imports, backup jobs, image regeneration and unoptimised custom code can legitimately take longer than the timeout.

Third Party API Calls That Hang

A page waits on an external service, such as a payment gateway, a shipping rate lookup or a licence check, that’s slow or unresponsive. If your code has no timeout of its own, your page inherits the outside service’s bad day.

Overloaded Backend Server

High CPU or memory usage from other processes slows every request, pushing normal response times past the threshold. On shared hosting that can include other accounts on the same server.

Misconfigured or Too Tight Timeout Settings

Settings on the reverse proxy, load balancer or CDN can cut off requests that would otherwise complete. A default left over from a template, or a CDN’s fixed limit, often lies behind a timeout on one specific slow page.

Network Congestion or Routing Issues

Delays between the proxy and the origin, especially across regions, can eat the time budget before your application even starts.

Step-by-Step Fix for a 504 Gateway Timeout Error

1. Identify which page or action triggers the timeout. A 504 on one page (a large report, a checkout step, an import) points to a slow query or script. A site wide 504 points to overload or a network issue.
2. Reload once, then test from another network. A single 504 can be a passing hiccup. Repeatability on the same URL tells you it’s real.
3. Note how long it takes to fail. If the error always arrives at almost exactly the same number of seconds, a timeout setting is cutting you off. The number often matches a known CDN or proxy default, which tells you which layer to inspect.
4. Check the database’s slow query log if you have access, and optimise or add indexes for any query that takes more than a second or two. On WordPress, a query monitoring plugin used briefly on a staging copy will reveal the heaviest queries.
5. Check server resource usage (CPU, RAM, database connections) for sustained high usage around the time of the error.
6. Review third party calls on the affected page. Add timeouts and fallbacks so a slow external service can’t hold your own response hostage. Disable integrations one at a time to find the slow one.
7. Look at timeout settings at each layer (CDN, proxy, web server, PHP max_execution_time). Raise them modestly for pages that are legitimately slow but correct, as a short term measure while you fix the real speed problem.
8. Optimise the slow process itself. Reduce an export’s size, add pagination, cache an expensive result, or move the heavy work into a background job and show the user a progress message.
9. Test after each change on the specific page that failed, not just the homepage, since the fault is often page specific.
10. Escalate to hosting support with the specific URL and timestamp if server logs show consistent CPU or database saturation that a code fix alone doesn’t resolve.

When It’s Your Fault and When It’s the Host’s

Most 504s come from the application, which makes them yours to fix, even when the host’s server is the thing that’s slow. A heavy query, a runaway plugin and an unprotected external call are all in your code and configuration.

It becomes the host’s problem when the server is starved of resources regardless of what you run, when neighbouring accounts on shared hosting are hogging the machine, when their network or load balancer is introducing delay, or when a limit on their platform (such as a fixed maximum execution time you can’t change) is shorter than a reasonable request needs. The telltale sign is intermittent timeouts on pages that are normally quick, with no change on your part.

A fair trade-off to keep in mind: raising the timeout is tempting and sometimes the right call for a rare admin task, but on visitor facing pages a long wait is nearly as bad as an error. Visitors leave long before a generous timeout fires, so the goal is a fast response, not a patient one.

How to Prevent 504 Gateway Timeout Errors

• Reduce server response time proactively. See our guide to reducing TTFB for the caching, database and server side techniques that prevent slow responses before they reach a timeout.
• Move heavy, long running tasks (bulk emails, large exports, report generation) to background jobs or queues instead of live page requests.
• Set realistic, monitored timeout values rather than defaults inherited from a template.
• Watch database query performance as your data grows, and add indexes before a table becomes a problem.
• Give every outbound API call a short timeout and a graceful fallback.
• Cache expensive results so the same slow work isn’t repeated for every visitor.
• Match your hosting plan to your workload. A 504 that only appears under load is often a sizing problem as much as a code problem. See best hosting for high traffic sites if your traffic has outgrown your current plan.

When to Contact Your Host

Contact your host when server logs show sustained resource saturation (CPU, memory, database connections) that persists after you’ve optimised the slow query or script on your end. On shared hosting, a neighbouring account consuming shared resources can also cause intermittent 504s that only your host can diagnose and resolve. Include the exact URL, the times, how many seconds it takes before the error appears, and what you have already ruled out. That last detail keeps the conversation from starting at square one. See the common hosting errors overview for how a 504 relates to the other server error codes.

FAQ

Is a 504 error the same as my site crashing? No. A 504 means a specific request took too long to complete, not that the whole site is down. Other pages on the same site often load normally while one slow page times out.

Will simply raising the timeout limit fix a 504 error permanently? It can mask the symptom short term. But if the underlying query or script is genuinely slow, raising the timeout just delays the same failure at a higher threshold, and visitors wait longer in the meantime. Fix the slow process first.

Can a slow third party plugin cause a 504 error? Yes. A plugin or integration that calls an external API without a reasonable timeout of its own is a common and easily missed cause. Check any plugin that connects to an outside service first.

Does a CDN help prevent 504 errors? A CDN caches and serves static content quickly, but it can’t speed up a genuinely slow dynamic request to your origin. For that, the fix has to happen at the database or application layer. A CDN can even be the source of the timeout if its limit is shorter than your slowest page.

Why do I get a 504 when importing or exporting a large file? Because the work takes longer than the gateway will wait. Break the job into smaller batches, run it as a background task, or use the host’s command line tools if they offer them.