504 Gateway Timeout 5xx

What does 504 mean?

A 504 Gateway Timeout response means a server acting as a gateway or proxy — load balancer, reverse proxy, CDN — sent a request to an upstream server but didn't receive a response within its configured time limit. Unlike 502 (which means the proxy got something invalid or nothing at all immediately), 504 specifically means the proxy was waiting, and gave up before getting any response.

This distinction matters for debugging: a 504 tells you the upstream server is likely still processing the request — it's just taking too long — whereas a 502 more often indicates the connection itself failed outright.

How a 504 behaves

• It's generated by the proxy/gateway, based on its own timeout configuration — not by the origin server, which may still be working on the request even after the proxy has given up and returned 504 to the client
• It's not cacheable — represents a timing issue specific to that request
• The underlying operation might still complete — if a 504 comes from a proxy timing out on a long-running database query or report generation, that query may continue running on the server even though the client already received a 504; this can lead to confusing situations where "it failed" but the side effect (e.g., a record being created) happens anyway
• Timeout thresholds vary by layer — a CDN, a load balancer, and a web server each typically have their own configurable timeout values, and the shortest one in the chain determines when a 504 appears

Common causes

If you're building/operating the infrastructure:

• A slow database query, external API call, or heavy computation causes the application to take longer than the proxy's timeout to respond
• A timeout misconfiguration — the proxy's timeout is shorter than the application's typical (legitimate) processing time for certain operations
• The application is overloaded and requests are queuing up, taking longer to even start processing than the timeout allows
• A downstream dependency (third-party API, microservice) the application calls is itself slow or hanging, and the application doesn't have its own shorter timeout to fail faster with a clearer error

If you're calling an API:

• You're hitting an endpoint that performs a genuinely long-running operation (large report generation, bulk data export, complex computation) that exceeds the API's gateway timeout
• The API is experiencing degraded performance — requests that normally complete quickly are taking much longer than usual

If you're a website visitor:

• You triggered an action that requires significant server-side processing (e.g., generating a large export, uploading and processing a large file) and the operation took longer than the server's configured limit

How to fix it

As an API/website builder:

• For genuinely long-running operations, move them to a background job/queue and return immediately (202 Accepted, or a 200 with a "processing" status the client can poll) rather than making the client wait through a synchronous request
• Profile and optimize slow database queries or external calls that are causing requests to exceed timeout thresholds
• Align timeout configurations across your stack — if your application is designed to take up to 60 seconds for a specific operation, make sure the proxy/load balancer/CDN timeouts in front of it are configured to allow at least that long for that endpoint
• Implement your own internal timeouts for calls to third-party services, so a hanging dependency fails fast with a clear error rather than causing the entire request to hang until the outer proxy times out
• Be aware that a 504 doesn't necessarily mean the operation failed server-side — for operations with side effects, consider idempotency keys so a client retry after a 504 doesn't cause duplicate actions

As an API consumer:

• For operations prone to 504s (large exports, bulk operations), check if the API offers an asynchronous pattern — submit a job, then poll for completion — rather than a single long synchronous request
• Increase your own client-side timeout if you know an operation is expected to take longer than typical, but be aware the server's gateway timeout is what ultimately determines the 504, not your client settings
• Be cautious about retrying after a 504 for non-idempotent operations (like payments or record creation) — the original request might have actually completed server-side despite the timeout

As a website visitor:

• For actions like large file uploads or exports, try breaking the task into smaller pieces if the site supports it
• Wait and check whether the action actually completed despite the timeout message — sometimes the result appears even though the page showed an error
• Try again during off-peak hours if the issue seems related to server load

504 vs related codes

Real-world examples

Long-running report generation, bulk data exports, and large file processing endpoints are classic sources of 504s — many APIs that support these operations explicitly document an asynchronous pattern (submit a job, receive a job ID, poll a status endpoint) specifically to avoid synchronous requests that would otherwise hit gateway timeouts. CDNs like Cloudflare have their own timeout settings for how long they'll wait for an origin server response, separate from any timeout configured on the origin server itself — meaning an origin server timeout setting alone doesn't guarantee a 504 won't appear if the CDN's timeout is shorter.

SEO implications

504s are treated similarly to other 5xx errors by search engines — an indication of temporary server trouble. Since 504s often stem from slow individual operations rather than total site outages, their SEO impact is usually limited to the specific pages/endpoints affected, rather than site-wide. However, if 504s are happening on pages search engines are actively trying to crawl (e.g., pages that trigger expensive server-side rendering), repeated timeouts during crawl attempts can reduce how often those specific pages get successfully indexed.

FAQ

What's the difference between 502 and 504?

502 typically means the proxy got an invalid response or couldn't connect at all — often a quick failure. 504 means the proxy successfully sent the request but gave up waiting for a response after its timeout period elapsed — the upstream server might still be processing.

If I get a 504, did my request actually do anything on the server?

It might have. A 504 means the proxy stopped waiting — it doesn't necessarily mean the origin server stopped processing. For operations with side effects (creating records, processing payments), this ambiguity is exactly why idempotency mechanisms matter — so a retry after a 504 doesn't cause duplicate actions if the original request actually completed.

Why does increasing my own request timeout not fix a 504?

Because the 504 is generated by a proxy (load balancer, CDN, reverse proxy) based on its configured timeout — not by your client. Your client's timeout setting only controls how long your client waits; it has no effect on the server-side proxy's timeout, which is what actually produces the 504.

What's the best way to handle operations that might take a long time?

Move them to an asynchronous pattern: the client submits the request and immediately gets a response (often 202 Accepted) with a way to check status later (polling an endpoint, a webhook, etc.), rather than holding a single request open until the operation completes.

Can different parts of the same infrastructure have different timeout settings?

Yes, commonly. A CDN, a load balancer, and the web server itself can each have independently configured timeouts. The shortest timeout in the chain is the one that determines when a 504 appears, even if the others are configured more generously.

Fun fact

504 is sometimes jokingly called the "patience limit" status code among developers — it's less about anything being technically wrong and more about a proxy literally running out of patience waiting for an answer, which is part of why 504s can be among the most frustrating to debug: the request might be working perfectly, just too slowly for the layer that gave up first.