What Is a 504 Gateway Timeout Error?
A 504 Gateway Timeout error is an HTTP status code meaning a server acting as a gateway or proxy waited for a response from an upstream server and did not get one in time, so it gave up. Unlike a 502, where the upstream returned a bad answer, a 504 means the upstream returned no answer within the allowed window. It points to a slow or unresponsive backend - an overloaded application, a stuck database query, or a network problem between servers - not something the visitor can fix.
- Status class
- A 5xx code: a gateway timed out waiting for the upstream (MDN Web Docs)
- Meaning
- The gateway did not receive a timely response from the upstream server (RFC 9110)
- Versus 502
- 504 is no response in time; 502 is an invalid response
- Common causes
- Overloaded backend, slow database queries, low timeout limits, or network issues
- Often performance-related
- Frequently tied to slow code or an under-resourced server
- Not the visitor
- The user cannot fix it; the server or host must
What a 504 error means #
A 504 Gateway Timeout error occurs when a gateway or proxy - the front-end server handling the browser's request - waits for a reply from an upstream server and never receives one within its time limit, so it stops waiting and returns a 504. In a typical stack, a reverse proxy, CDN, or load balancer forwards each request to a back-end application or origin server; if that backend is too slow to respond, the proxy times out. The defining feature is silence: with a 504 the upstream did not answer in time, as opposed to a 502 where it answered badly. That usually means the backend is overloaded, stuck on a slow operation like a heavy database query, or unreachable across the network. Because it is fundamentally a server-side performance and connectivity issue, the visitor cannot resolve it - refreshing may help only if the slowness was momentary. Recurring 504s are a strong sign your backend needs /services/speed-optimization or more capacity from /services/managed-hosting, since the server is consistently answering slower than the gateway will tolerate.
504 versus 502 and other 5xx codes #
The 5xx family all point to server-side failures, but each says something specific, and telling them apart speeds up the fix. A 500 is a generic 'something broke' with no detail. A 502 Bad Gateway means the proxy got an invalid or empty response from upstream - the backend answered, but wrongly. A 503 Service Unavailable means the server is temporarily unable to serve, often intentionally for maintenance or due to overload. A 504 Gateway Timeout is distinct: the upstream did not answer at all within the timeout window. The practical difference between a 502 and a 504 matters most. A 502 often indicates a crashed or misconfigured backend returning garbage, while a 504 indicates a backend that is alive but too slow, or a network path that is not completing. That points diagnosis in different directions - for a 504 you investigate performance and connectivity, not corruption. Recognizing which 5xx you have narrows the search immediately, and when timeouts accompany general sluggishness, a /services/speed-optimization audit usually finds the slow queries or code behind them.
Common causes of a gateway timeout #
Most 504s trace back to something upstream being too slow. The leading cause is an overloaded backend: under heavy traffic the application server cannot process requests fast enough, so responses exceed the gateway's timeout. Slow operations are another classic trigger - a poorly optimized or blocking database query, a heavy report, an external API call that hangs, or a long-running script that outlasts the allowed window. Timeout settings themselves can be the problem: if the proxy's timeout is set very low relative to how long legitimate requests take, normal-but-slow responses get cut off as 504s. Network issues between the gateway and origin - a firewall dropping packets, DNS resolution failing, or an unreachable origin - also produce timeouts. On CDN setups, an origin that is slow or intermittently unreachable triggers edge 504s. Occasionally a backend deadlock or exhausted connection pool leaves requests waiting indefinitely. Because the theme is slowness or unreachability rather than corruption, the fix usually combines performance work with correct timeout configuration, often through /services/speed-optimization and, for database-bound slowness, tuning covered by /services/database-services.
Diagnosing slow upstreams #
Diagnosing a 504 means finding what is slow or unreachable upstream. Start with the proxy's error log, which records upstream timeout messages and often the request that stalled. Then measure how long the backend actually takes to respond directly, bypassing the proxy, to confirm whether the origin itself is slow. The commands below show checking an Nginx error log for timeout entries and timing a direct request to the backend. Slow database queries are a frequent culprit, so reviewing the database's slow-query log or the application's performance profiling narrows it further. If a request that should take milliseconds takes many seconds, you have found your problem area. Also verify the gateway's timeout settings are reasonable for your workload. If you lack server access, your /services/managed-hosting provider can gather these measurements. The goal is to locate the specific slow operation - a query, an API call, or an overloaded process - rather than blindly raising timeouts, which only hides the symptom while visitors keep waiting through slow, near-timeout responses.
# Nginx error log - look for 'upstream timed out'
grep 'upstream timed out' /var/log/nginx/error.log | tail
# Time a direct request to the backend origin
curl -o /dev/null -s -w 'total: %{time_total}s\n' http://127.0.0.1:8080/
# MySQL: check for slow queries (if slow log enabled)
tail -n 30 /var/log/mysql/slow.logFirst fixes for site owners #
Facing a 504, work from quick checks toward deeper causes. First refresh and retry from another network, since a momentary slowdown can clear. If it persists, look at what the site was doing: a specific slow page, a heavy admin task, an import, or a report often triggers timeouts, and avoiding or optimizing that operation gives immediate relief. Check backend load - high CPU, saturated memory, or a maxed-out database means the server is simply too slow under current demand, so reducing load through caching or adding resources helps directly. Restarting a stuck application or database service can clear a deadlocked process. Review recent changes such as a new plugin, query, or integration that may be running slowly or hanging on an external call. Raising the proxy timeout is sometimes appropriate for genuinely long tasks, but treat it as a last resort, because it masks slowness rather than curing it. For recurring 504s, escalate: a /services/website-rescue or /services/speed-optimization engagement can find the slow query or bottleneck and fix the root cause rather than the symptom.
CDN, proxy, and timeout settings #
Because 504s hinge on timeouts, the proxy and CDN configuration deserve attention. Every gateway - Nginx, a load balancer, or a CDN like Cloudflare - enforces a limit on how long it waits for the origin, and a 504 fires when the origin exceeds it. If legitimate requests genuinely need longer, such as a large export, you can raise that timeout, but the better fix is usually to make the operation faster or run it in the background rather than during a web request. Ensure the proxy, application, and any load-balancer timeouts are aligned so one layer does not cut off another prematurely. On CDN setups, an edge 504 typically means your origin was too slow or unreachable, so the work is at your host, not the CDN - confirm the origin responds quickly and is not blocking the CDN. Misaligned or aggressive timeouts turn slow-but-valid responses into errors, while excessively long ones leave visitors staring at a spinner. Tuning these settings is part of a proper /services/vps-cloud-setup or /services/managed-hosting configuration, where the whole stack's timing works together.
Performance, users, and SEO #
A 504 is, at heart, a performance failure with the same costs as any outage. For visitors, a page that spins and then errors is worse than a merely slow one; they wait, get nothing, and leave, and if the timeout hits during checkout or form submission the transaction is lost. Frequent 504s brand your site as slow and unreliable, driving customers to faster competitors. For SEO, sustained 5xx responses signal instability to search engines, which can reduce crawl rate and, over time, harm rankings and index coverage (Google Search Central). Beyond the error itself, the underlying slowness that causes 504s also drags down Core Web Vitals, which directly affects user experience and search performance even when requests do not fully time out. In other words, the same backend sluggishness hurts you twice. Monitoring helps you catch it: /tools/website-down-checker shows whether your site is timing out now, and performance monitoring reveals creeping response times before they cross the threshold. Addressing the root slowness through /services/speed-optimization protects rankings, conversions, and the everyday experience of every visitor.
Preventing 504s and what we advise #
Preventing 504s is mostly about backend performance and sensible timeouts. Optimize the slow operations that cause them: tune database queries and indexes with help from /services/database-services, cache expensive pages and data through /services/speed-optimization, and move long-running tasks like imports, reports, and third-party API calls out of the web request into background jobs so they never block a page load. Size your hosting for real peak traffic so the backend does not crawl under load, and align proxy, application, and load-balancer timeouts to your genuine workload. Add performance and uptime monitoring so rising response times alert you before they become timeouts. For businesses without technical staff, a /services/care-plans subscription plus solid /services/managed-hosting covers monitoring, tuning, and rapid response, keeping timeouts rare. When a 504 does occur, resist simply raising the timeout; find the slow query, script, or overloaded resource and fix it, because masking slowness only postpones the problem. A fast, well-resourced backend behind correctly tuned gateways is the durable cure for gateway timeouts.
FAQ
What is the difference between a 502 and a 504 error?
Both involve a gateway and an upstream server. A 504 Gateway Timeout means the upstream did not respond in time, so the gateway gave up waiting. A 502 Bad Gateway means the upstream did respond, but with an invalid or empty answer. A 504 is silence; a 502 is a bad reply.
Why does my site keep timing out with a 504?
Usually because the backend is consistently too slow - an overloaded server, a heavy or stuck database query, a hanging external API call, or a timeout set too low for legitimate work. The server answers slower than the gateway will wait. Fixing it means optimizing the slow operation and adding resources, not just refreshing.
Can I fix a 504 by increasing the timeout?
Sometimes, for genuinely long tasks like large exports, but treat it as a last resort. Raising the timeout hides the slowness rather than curing it, so visitors still wait a long time. The better fix is to speed up the slow query or script, or run long tasks in the background.
Is a 504 error caused by my internet connection?
No. A 504 is a server-side timeout between a gateway and an upstream server, not a problem with the visitor's connection. Nothing the user does will fix it. The slowness or unreachability lies in the website's backend, database, or network path, and only the site owner or host can resolve it.
Do 504 errors affect SEO?
They can. Persistent 5xx errors, including 504s, signal instability to search engines, which may reduce crawl rate and, over time, cost rankings. The underlying slowness also harms Core Web Vitals, hurting user experience and search performance even without a full timeout. Fixing backend speed protects both rankings and conversions.
How do I prevent 504 gateway timeouts?
Optimize slow database queries, cache expensive pages, and move long-running tasks to background jobs so they never block a request. Size hosting for peak traffic, align proxy and application timeouts to your real workload, and monitor response times so you are alerted before slowness becomes a timeout. A care plan can handle this ongoing.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?