HTTP 504 Gateway Timeout

Quick reference

What it means

In a typical production web architecture, requests pass through one or more layers before reaching the application: CDN → load balancer → application server → database. A 504 originates at whichever layer is acting as a gateway when its upstream does not respond within the configured timeout.

A Cloudflare or Nginx 504 means the application server did not respond in time. An application server 504 from within a microservices architecture means a downstream service did not respond. The 504 always comes from the proxy layer; the problem is always in the layer behind it.

This is the key distinction from 500: a 500 means the application itself failed. A 504 means the application either never responded or took too long — the proxy gave up waiting.

504 vs 502

Both involve proxy failures: 502 means the proxy received an invalid or empty response from upstream. 504 means the proxy received no response before its timeout expired. 502 is "got a bad answer"; 504 is "got no answer in time."

Common causes

Slow database query

The most common application-level cause. A request triggers a slow query — missing index, table scan, deadlock wait, or unexpectedly large result set — that takes longer than the proxy timeout. The proxy times out and returns 504; the database query may still be running.

Application server overload

The application server's request queue is full. New requests wait in queue longer than the proxy's timeout before being processed. Symptoms: 504 rate correlates with high traffic spikes; resolves when load decreases.

Proxy timeout configured too short

The proxy timeout is shorter than the expected processing time for legitimate long-running requests (large file uploads, complex report generation, batch operations). Increase the proxy timeout for those specific routes, or implement async processing with webhook callbacks for operations that take more than a few seconds.

Downstream service timeout in microservices

A microservice calls a downstream dependency that is slow or unavailable. Without a circuit breaker pattern, the calling service holds the connection open until its own timeout expires, causing 504s to propagate up the call chain.

Network partition or routing issue

Network-level connectivity problems between the proxy and the upstream server. The upstream is running but unreachable. Verify network connectivity, DNS resolution, and firewall rules between the proxy and upstream layers.

How to diagnose a 504

1. Identify which proxy is returning 504. Check the response headers for Server or Via headers indicating the proxy layer. The 504 originates at the first layer that timed out.
2. Check upstream health. Is the application server running? Check process status, memory, CPU, and connection counts. A server under memory pressure or at connection pool capacity will be slow to respond.
3. Check application logs for slow requests. Correlate the 504 timestamp with slow request entries in the application log. Slow queries, external API calls, or heavy computation will appear as long-duration entries.
4. Compare proxy timeout vs. application response time. If the application regularly takes 25 seconds for certain operations and the proxy timeout is 20 seconds, increase the timeout for that route or optimize the operation.
5. Check for correlation with specific endpoints. If only certain routes produce 504s, the slow operation is specific to that code path, not a general capacity issue.

504 vs 500 vs 502 vs 503

See also: 500 vs 504 · 502 vs 504 · 503 vs 504 · 408 vs 504

Related resources

On this site: HTTP 504 diagnosis guide · HTTP 500 Internal Server Error · HTTP 502 Bad Gateway · HTTP 503 Service Unavailable · All 5xx server errors

Comparisons: 500 vs 504 · 502 vs 504 · 503 vs 504 · 408 vs 504

Standards: RFC 9110 §15.6.5 · IANA Registry · MDN Web Docs: 504