A proxy didn’t get a response in time.
When to use it
The upstream app is too slow or hanging.
Common causes and fixes
The proxy gave up waiting for the upstream. Typical causes: a slow database query or external API call, a deadlocked worker, too few workers for the traffic, or a firewall silently dropping packets. Timeouts are layered, and the shortest wins: nginx proxy_read_timeout defaults to 60 seconds, AWS ALB idles out after 60, API Gateway after 29, and Cloudflare shows its own 524 after 100 seconds.
Find where the time goes: check the app’s logs for request duration, look for slow queries, and time the same request against the origin directly, bypassing the proxy. Raising timeouts only hides the problem; move long jobs to a background worker and return 202 with a status URL. The work may still finish after the 504, so retrying non-idempotent requests can duplicate it.
Server error (5xx)
5xx codes are server errors: the request may be fine, but the server or something behind it failed. These are worth alerting on.
What it looks like
HTTP/1.1 504 Gateway TimeoutHow to send it
| Node.js / Express | res.status(504).end() |
|---|---|
| Python / Flask | return '', 504 |
| nginx | return 504; |
How to check it
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/