Image Source: Fehlermeldung – Error 504 – Gateway Timeout, By: ccnull.de Bilddatenbank, Source: flickr, License: by | //creativecommons.org/licenses/by/2.0/
You try to load a page, your browser spins for what feels like forever, and then it gives up and delivers a blunt verdict: 504 – Gateway Timeout. Unlike errors that appear instantly, the 504 makes you wait for it. That waiting is actually the whole point (the server was expecting a response from somewhere upstream, kept waiting, and eventually gave up).
The 504 is one of the more technically specific errors in the 5xx family because it tells you something precise about what went wrong: not that a server crashed, not that a page is missing, but that a conversation between two servers started, a deadline passed, and nobody answered in time. For visitors it’s a patience-testing experience. For webmasters it’s a signal that something in the server chain is running dangerously slow. And for SEO, a site that regularly serves 504s to crawlers is quietly losing ground in ways that can take months to recover from.
Let’s get into exactly what a 504 is, what causes it, how to diagnose and fix it, and what you need to do to protect your rankings when it happens.
What Is a 504 Gateway Timeout Error?
A 504 Gateway Timeout is an HTTP status code returned when a server acting as a gateway or proxy did not receive a timely response from an upstream server it needed to complete the request. The gateway server asked the upstream server for something, set a clock running, and the upstream server didn’t respond before that clock ran out.
It lives in the 5xx family of HTTP status codes, meaning it’s a server-side error. The client (your browser, a search engine crawler, an API consumer) made a perfectly valid request. The failure happened entirely within the server infrastructure trying to fulfil it.
The timeout element is what makes the 504 distinct. The upstream server didn’t crash (that would be a 502). It didn’t explicitly refuse the request (that would be a 500 or 503). It simply took too long. Whether that’s because it was overloaded, processing something expensive, waiting on its own dependencies, or had silently failed without the gateway knowing, the result from the gateway’s perspective is the same: silence past the deadline equals a 504.
Why Does It Happen?
504 errors almost always trace back to one of a handful of root causes, most of them involving either a slow upstream server or a breakdown in the communication pathway between servers.
Slow or overloaded upstream application servers are the most common cause. When an application server (running PHP, Node.js, Python, Ruby, or any other runtime) is under heavy load, individual requests take longer to process. If that processing time exceeds the timeout threshold configured on the gateway in front of it, the gateway stops waiting and returns a 504 to the client. The application server may eventually finish processing the request, but by then the gateway has already given up and moved on.
Heavy or unoptimised database queries are a leading cause of the slow upstream responses that trigger 504s. A query without proper indexing performing a full table scan on a large dataset, a complex join across multiple tables, or a deadlock situation where queries are blocking each other can hold up the application server for far longer than the gateway’s timeout threshold. The application is waiting for the database, the gateway is waiting for the application, and eventually the gateway runs out of patience.
PHP execution time limits interact with gateway timeouts in a way that catches many WordPress and PHP site owners off guard. PHP has its own max_execution_time setting that limits how long a script can run. If the PHP execution time limit is shorter than the gateway timeout, you’ll get a 500 or a white screen rather than a 504. But if the gateway times out first (because the PHP process is running a legitimately long operation), the result is a 504 from the gateway even though the PHP script is technically still alive and running behind it.
Network latency and connectivity issues between servers can cause 504s in multi-server and cloud environments. If the gateway and the upstream application server are communicating over a network path that experiences packet loss, routing problems, or high latency (whether due to misconfigured VPC settings, physical network issues, or DNS resolution problems), requests may take far longer than expected to traverse the gap and trigger gateway timeouts.
External API calls within the application are an increasingly common cause as modern web applications integrate with third-party services. If your application makes a synchronous call to an external payment gateway, a shipping API, a data enrichment service, or any other third-party endpoint (and that endpoint is slow or unresponsive), your application server stalls waiting for the response. If it stalls long enough, the gateway in front of your application gives up and returns a 504 to the visitor, even though your own server is technically fine.
Upstream server crashes that aren’t immediately detected can also produce 504s. If an application server crashes but the gateway doesn’t immediately recognise the connection as broken [due to TCP keepalive settings or connection pooling behaviour], the gateway may continue waiting for a response that will never come until the timeout window expires. This produces a 504 rather than the immediate 502 you’d expect from a recognised crash.
Misconfigured timeout values create 504s that aren’t caused by genuine slowness but by timeout thresholds set too aggressively short. If a gateway timeout is set to five seconds but legitimate requests on a complex application regularly take seven or eight seconds, you’ll see 504s even when the upstream server is performing normally. Calibrating timeout values to match the realistic performance profile of the application is an important and often overlooked configuration task.
How a 504 Differs From Its Neighbours
The 5xx family produces several codes that are closely related but meaningfully different in what they tell you about the failure.
A 500 is the upstream server breaking internally without knowing specifically why. The problem is within the server itself.
A 502 is the gateway receiving an invalid or corrupt response from the upstream server. The upstream responded, but what it sent back was garbage or nothing coherent.
A 503 is the server explicitly acknowledging it’s temporarily unavailable (overloaded or in maintenance). It knows it can’t handle the request and says so immediately.
A 504 is the gateway waiting for a valid response from the upstream server and not receiving one within the allowed time window. The upstream didn’t crash visibly, didn’t send a bad response (it just didn’t respond at all before the deadline).
The practical distinction between a 502 and a 504 is important for diagnosis. A 502 points to a bad response (look at what the upstream is sending). A 504 points to a slow or unresponsive upstream (look at why it’s taking too long or not responding at all).
The SEO Consequences of a 504 Error
504 errors carry the same fundamental SEO risks as other 5xx errors, but with some characteristics specific to timeout-based failures that make them particularly damaging in certain scenarios.
Search engine crawlers encountering a 504 receive no content. The page cannot be rendered, evaluated, or indexed during the timeout event. For pages that are supposed to be publicly accessible and indexed, a 504 is functionally equivalent to the page not existing from the crawler’s perspective at that moment.
The duration problem is more pronounced with 504s than with some other error types. Because a 504 involves waiting (the gateway sits there until the timeout expires before returning the error), crawlers spend significantly more time on each failed request than they would with an instant 404 or 500. On a site with recurring 504s, this time cost compounds quickly and can significantly reduce the number of pages Googlebot successfully crawls in a given session, effectively throttling your indexing throughput.
Intermittent 504s caused by database query slowness or external API latency are particularly insidious from an SEO perspective. They may not be severe enough to trigger uptime monitors (because the site isn’t fully down), but they generate a steady stream of timeout errors in Google Search Console that gradually reduce crawl frequency and erode indexing coverage. These are the 504s that webmasters often discover months after they began, by which point rankings have quietly slipped.
For e-commerce sites, 504s on product pages, category pages, or checkout flows during peak traffic periods (sales events, holiday seasons) are especially costly. The exact moments when crawler activity is highest (driven by increased user signals) are often the moments when server load is greatest and timeout risks are highest.
How to Diagnose a 504 Error
Diagnosing a 504 requires tracing the timeout back to its origin in the server chain.
Start with your gateway or reverse proxy logs. Nginx, Apache, HAProxy, AWS ALB, and Cloudflare all log upstream timeout events. The gateway log will tell you which upstream server timed out, at what time, and how long the gateway waited before giving up. This gives you your starting timestamp and the specific upstream to investigate.
Check upstream application server performance logs. Match the timestamp from the gateway log with your application server logs. Look for requests that were still processing at the time of the timeout. If PHP-FPM logs show workers busy processing long-running requests, or if your application framework’s logs show slow request processing times correlating with the 504 events, the application layer is your culprit.
Profile your database queries. Enable MySQL or MariaDB slow query logging and review the slow query log for queries running at the time of the 504 events. Queries taking multiple seconds are prime candidates for causing the upstream slowness that triggers gateway timeouts. Tools like MySQL’s EXPLAIN command will show you whether a slow query lacks proper indexing.
Check external API response times. If your application calls external services, review the response time logs for those calls. A third-party API returning responses in eight seconds when your gateway timeout is set to ten seconds is a disaster waiting to happen under any load at all. Implement timeouts on your outbound API calls so a slow third party can’t hold your application hostage.
Review server resource utilisation at the time of the 504 events. High CPU, memory pressure, or swap usage on the upstream application server will slow all request processing and increase the likelihood of gateway timeouts. Correlate resource utilisation graphs with 504 event timestamps to confirm whether resource starvation is contributing to the slowness.
Test your timeout configuration values. Compare your gateway timeout settings (proxy_read_timeout in Nginx, ProxyTimeout in Apache, timeout settings in your load balancer) with the realistic processing time of your application under normal and peak load. If your timeout values are shorter than legitimate request processing times, you’re generating artificial 504s that don’t reflect a genuine failure.
What Webmasters Can Do to Prevent 504 Errors
Preventing 504s requires addressing both the underlying slowness that causes upstream timeouts and the configuration that determines when those timeouts trigger.
Optimise your database queries. Add appropriate indexes to columns used in WHERE clauses, JOIN conditions, and ORDER BY operations. Use MySQL’s slow query log to identify the worst offenders and profile them with EXPLAIN. Implement query caching where appropriate. For WordPress sites, plugins like Query Monitor will surface slow database queries without requiring server-level log access.
Implement application-level caching. Serving pages from a cache (whether a full-page cache, an object cache using Redis or Memcached, or a CDN edge cache) eliminates the database queries and application processing that cause slow upstream responses. A cached page is returned in milliseconds rather than seconds, making gateway timeouts essentially impossible for cached content.
Set sensible timeouts on all outbound API calls. Every call your application makes to an external service should have an explicit timeout set on it. If a payment gateway or shipping API takes more than three seconds to respond, your application should give up on that call and handle the failure gracefully rather than stalling indefinitely and causing a cascade of 504s for waiting visitors.
Tune your gateway timeout values to match your application’s realistic performance profile. Don’t set gateway timeouts shorter than the longest legitimate request your application needs to process. Equally, don’t set them so long that a genuinely failed upstream holds connections open for minutes at a time. Finding the right balance requires profiling your application under realistic load conditions.
Scale your application server capacity to match your traffic. Resource-starved application servers process requests slowly, and slow request processing causes gateway timeouts. Whether that means upgrading your hosting plan, adding more PHP-FPM workers, moving to a VPS or dedicated server, or implementing horizontal scaling in a cloud environment, your infrastructure needs enough headroom to process requests within your timeout thresholds even during traffic peaks.
Use a CDN to absorb traffic and cache content at the edge. A CDN like Cloudflare not only serves cached content without touching your origin server, it also provides its own timeout handling and origin health monitoring. Cloudflare’s Argo Smart Routing can reduce latency between the CDN edge and your origin, directly reducing the timeout risk for uncached requests.
Monitor for slow requests proactively. Set up application performance monitoring (APM) with tools like New Relic, Datadog APM, or the open-source equivalent Elastic APM. These tools track request processing times across your entire application stack, alerting you when specific endpoints or database queries start trending toward your timeout thresholds before they actually start causing 504s.
Set up uptime monitoring configured to detect 5xx responses. Standard uptime monitors check whether your site returns a response at all. Configure yours to also alert on 5xx status codes so that intermittent 504s (which may not take the site fully down) are caught and investigated quickly rather than accumulating silently in Search Console.
A Final Word
The 504 Gateway Timeout is infrastructure’s way of telling you that somewhere in your server chain, something is running too slowly to keep up with demand (and the systems in front of it have lost patience). It’s a performance problem as much as it is an availability problem, and solving it properly usually means looking at the full stack: gateway configuration, application performance, database query efficiency, external dependencies, and server resource capacity.
Getting this right matters not just for avoiding error pages but for the overall performance profile of your site. The same slow database queries and unoptimised application code that cause 504s under pressure are also responsible for the elevated page load times that drag down your Core Web Vitals scores and hurt your rankings even when the site is technically up and serving pages.
PCGuys uses affiliate links. If you purchase through our links we may earn a small commission at no cost to you.
If you want to get hands-on with the server environment where timeout configurations, application performance, and database optimisation actually happen, Alison offers a free course that covers exactly this territory: Design, Deliver, and Administer Web Applications using LAMP. It covers Linux, Apache, MySQL, and PHP in depth [the exact stack where most 504 timeout events originate], including how to eliminate single points of failure, manage server performance under load, reduce downtime, and scale your infrastructure as your traffic grows. Understanding how each layer of the LAMP stack communicates with the others is precisely the knowledge you need to diagnose and prevent the timeout cascades that cause 504s. It’s free, it’s practical, and it’s directly applicable to the problems this article covers.
For the complete picture of how server performance, technical configuration, and error handling connect to your search rankings across every major engine, SEO Fundamentals is the resource we recommend at PCGuys. The book covers everything from .htaccess configuration and redirect strategy to sitemap structure, robots.txt, hreflang, Core Web Vitals, mobile-first indexing, and multi-engine optimisation across Google, Bing, Yandex, Baidu, DuckDuckGo, Snipesearch, YaCy, and more. Built on over two decades of hands-on experience in server management, web development, and digital marketing, it’s a no-fluff, systematic guide designed to help you check every critical technical and content SEO box in one comprehensive sweep. If slow server performance has ever cost you rankings and you weren’t sure where to start fixing it, this book gives you the framework to approach it systematically and get it right.
