504 Gateway Timeout: what it means and how to fix it
A 504 Gateway Timeout means a proxy forwarded the request and the server behind it did not answer within the proxy’s time limit. The app is usually still running; it is just too slow for that request.
What causes a 504
- A slow database query, often one that got slower as a table grew.
- A slow call to another API with no timeout of its own.
- Long work inside a web request: a report, an export or an import that belongs in a background job.
- A service starved of CPU, so every request queues.
- A proxy timeout shorter than the work takes.
How to fix a 504
- Find the slow endpoint. Its p95 and p99 latency will sit close to the timeout.
- Move long work to a background job and return right away with a status the client can poll.
- Put timeouts on outbound calls so a slow dependency fails fast instead of holding the request.
- Raise the proxy timeout last, and only when the work is meant to take that long.
504 on nginx, Cloudflare and Vercel
- nginx returns 504 when
proxy_read_timeoutruns out before the app answers. - Cloudflare uses its own code, 524, when your origin accepted the connection but did not answer in time. Cloudflare 5xx errors.
- Vercel returns 504 with
FUNCTION_INVOCATION_TIMEOUTwhen a function runs past its maximum duration. Raise the duration in the function’s config, or move the work out of the request.
Catch it before the timeout
A 504 is the end of a slowdown you can usually watch build. Latency climbs first; clients start giving up next (they show as 499 status code in the proxy’s logs); timeouts come last. Watching p95 latency per service gives you the warning.