HTTP 504 Gateway Timeout — What It Means & How to Debug
HTTP 504 Gateway Timeout is an HTTP response status code that indicates a server acting as a gateway or proxy did not receive a timely response from an upstream server. The proxy was willing to wait only so long for the backend to respond, and the backend exceeded that limit.
What It Means
Defined in RFC 7231 Section 6.6.5, the 504 status code sits between 502 (bad response) and 503 (server overloaded) in the 5xx family. The gateway successfully connected to the upstream server and forwarded the request, but the upstream either never responded or took longer than the configured timeout.
Unlike a 502 (where the upstream returns garbage), a 504 means the upstream returned nothing at all within the expected time frame.
When It’s Sent
- Slow database queries — A complex SQL query takes 30 seconds, but the proxy timeout is 10 seconds.
- Upstream server overloaded — The backend is so busy that requests sit in its queue past the proxy timeout.
- External API timeout — Your application calls a third-party API that is slow or unresponsive, and the gateway times out waiting for your app server.
- Proxy timeout too low — The default proxy timeout (e.g., Nginx
proxy_read_timeout 60s) is not high enough for long-running requests. - Backend process deadlock — The application server is alive but stuck (e.g., a mutex deadlock), so it never sends a response.
Real Example
The following curl command hits an endpoint that deliberately sleeps before responding:
curl -v https://httpbin.org/delay/15Expected response (depending on proxy timeout configuration):
< HTTP/1.1 504 GATEWAY TIMEOUT
< Date: Sat, 20 Jun 2026 12:00:00 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 184
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>504 Gateway Timeout</title>
<h1>Gateway Timeout</h1>
<p>The server did not receive a timely response from an upstream server.</p>A typical Nginx 504 page:
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.24.0</center>
</body>
</html>How to Debug
Client-Side
- Retry with backoff — A 504 may be transient. Wait a few seconds and try again.
- Check the server status page — Large services often report degraded performance on their status dashboard.
- Simplify the request — If you sent a complex query or large payload, try a simpler request to see if the backend responds faster.
- Contact the administrator — If the error persists, report the URL and timestamp. Include the
X-Request-Idheader if present.
Server-Side
- Increase proxy timeout — Adjust
proxy_read_timeout(Nginx),ProxyTimeout(Apache), orTimeout(HAProxy) to match the expected response time of the slowest legitimate request. - Profile the upstream — Use application profiling tools (XHProf, Datadog APM, Jaeger) to identify why the backend is slow. Common culprits: N+1 queries, missing indexes, or external API calls.
- Implement streaming — If the backend generates a large response, stream it incrementally so the proxy sees data flowing before the timeout.
- Add health checks — Configure the proxy to detect and remove unresponsive upstreams from the pool.
- Use async processing — For long-running operations, accept the request immediately with a 202 Accepted and provide a status URL for polling.
- Review upstream logs — The backend may show slow query logs, error traces, or deadlock warnings.
Common Causes Table
| Scenario | Likely Cause | How to Fix |
|---|---|---|
| Complex analytics query | Query runs for minutes, proxy times out in 30s | Increase timeout for that route; optimize query; use materialized views |
| Third-party API slow | Upstream app calls external API with no timeout | Set a shorter timeout on external calls; use circuit breaker |
| Backend under heavy load | Request queue builds up past proxy timeout | Scale up; add connection pooling; rate-limit at proxy |
| Nginx default timeout | proxy_read_timeout set to 60s, request takes 90s | Increase timeout or optimize backend response time |
| Deadlocked database | Transaction A holds lock, Transaction B waits forever | Kill blocking transactions; fix locking order in code |
FAQ
Related Codes
HTTP 502 Bad Gateway — An upstream server returned an invalid response.
HTTP 503 Service Unavailable — The server is temporarily unable to handle the request.
HTTP 500 Internal Server Error — A generic server-side error.
HTTP 408 Request Timeout — The server timed out waiting for the client’s request.
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro