English 
French 
You submit a form, or click through to a page that should load in a second, and instead you’re staring at “504 Gateway Timeout.” The page never comes back at all, it just gives up.
A 504 Gateway Timeout means a server acting as a gateway or proxy sent a request to an upstream server and never got a response back within the allowed time. It’s not that the response was broken or invalid, like a 502. It’s that no response arrived in time, so the proxy gave up waiting and reported the timeout instead.
504 vs 502: What’s the Real Difference?
Both are gateway errors. Both point to a problem happening behind the scenes rather than in your browser. The difference comes down to timing versus content. A 502 means the proxy got a response and didn’t like what it saw. A 504 means the proxy never got a response at all before it stopped waiting.
Common Causes of a 504 Gateway Timeout
- Slow database queries. A query that takes too long to run can hold up an entire request until the timeout limit hits.
- Insufficient server resources. A server running low on CPU or memory processes requests slower, sometimes slow enough to exceed the timeout window.
- Traffic spikes. A sudden surge in visitors can back up the request queue faster than the server can clear it.
- Slow third-party API calls. If your site depends on an external service, a payment gateway, a shipping API, anything external, that’s responding slowly, your own server ends up waiting on it and timing out.
- Timeout settings that are too short. Some proxies and load balancers use timeout values that don’t account for legitimately slow operations, like large file uploads or complex report generation.
- DNS resolution delays. If the gateway is slow to resolve where the backend actually lives, that delay eats into the timeout budget before the real request even starts.
- Network congestion between servers. Even solid infrastructure hits occasional latency spikes between the proxy layer and the origin server.
Is the Site Down, or Just Slow for You?
A 504 can look identical to a full outage from where you’re sitting, but the site might just be struggling under load rather than fully down. Running a quick check with CheckSiteStatus tells you whether the site is unreachable for everyone or just slow to respond, which changes what you should actually do next.
How to Fix 504 Gateway Timeout as a Visitor
- Refresh the page. A lot of 504s are one-off timing issues that clear up on the next attempt.
- Wait a minute or two, then retry. If the server is dealing with a temporary load spike, giving it a bit of breathing room often helps.
- Try a different device or network. This rules out a local connectivity problem masquerading as a server issue.
- Disable any VPN you’re using. Routing through an extra hop adds latency that can push an already-slow request over the timeout limit.
- Check whether other people are seeing the same thing using a free website monitoring tool rather than assuming it’s just you.
- Avoid repeatedly resubmitting forms. If the timeout happened mid-submission, hitting submit again and again can pile up duplicate requests and make the backend’s problem worse.
How to Fix 504 Gateway Timeout as a Website Owner
Start with your slow query log. Most database systems can log queries that exceed a set duration. This is usually the fastest way to find the actual bottleneck rather than guessing at server configuration.
Optimize or index the slow queries you find. A missing index on a frequently queried column is one of the most common causes of a 504, and one of the easiest to fix once you’ve identified it.
Increase timeout values only after fixing the real bottleneck. Raising proxy_read_timeout in Nginx or a similar setting elsewhere can mask a symptom temporarily, but it doesn’t fix a genuinely slow process, it just makes visitors wait longer before seeing the same error.
Check your third-party integrations. If your server is waiting on an external API that’s having a bad day, the timeout may have nothing to do with your own code. Test your site’s response times directly to see where the delay is actually coming from.
Scale resources if load is the real driver. If the timeout correlates with traffic spikes, more server capacity, or better caching in front of your dynamic pages, address the root cause instead of the symptom.
Add a caching layer for expensive operations. Pages or endpoints that run heavy queries on every request benefit from caching the result, even for a short period, so the backend isn’t recalculating the same thing over and over.
Preventing Future 504 Errors
Timeouts tend to creep up gradually as traffic or data grows, so catching the trend early matters more than reacting after visitors start complaining. Ongoing checks with a website performance and response monitor let you watch response times over weeks and months, not just the moment something breaks, so you can act before slow responses turn into full timeouts. Combining that with downtime detection that flags issues within a minute means you’re usually fixing the problem before most of your visitors even notice it.
Not necessarily. A 504 means a specific request timed out waiting for a response, which can happen even while the rest of the site loads fine. A full outage usually shows up as connection failures across every page, not just slow ones.
Because more simultaneous requests mean more competition for limited server resources. Database connections, CPU, and memory all get stretched thinner, and requests that would normally finish quickly start taking long enough to hit the timeout limit.
It’s possible but less common than a server-side cause, since a 504 specifically means a server-to-server timeout happened. A slow or unstable connection on your end is more likely to produce a different kind of error, like a request that never completes at all.
A slow-loading page is still actively working, just taking its time. A 504 means the gateway server hit its limit and gave up waiting entirely, returning an error page instead of the content you asked for.
Rarely on its own. It buys more time for a slow request to finish, but if the underlying process is genuinely too slow, you’ve just delayed the same error and made visitors wait longer to see it. Fixing the actual bottleneck matters more.