504 Gateway Timeout: causes and how to fix it
504 Gateway Timeout means the reverse proxy (nginx, a load balancer) connected to your upstream but the upstream did not return a response within the configured timeout — the app is too slow or stuck.What causes 504 Gateway Timeout
A slow database query or external API call; the app is overloaded or thread-starved; a deadlock; or a proxy timeout set lower than the real work time.
How to diagnose it
Check the proxy error log for upstream timed out (110: Connection timed out). Measure the actual upstream response time; profile the slow endpoint and its downstream calls.
How to fix 504 Gateway Timeout
- Find and fix the slow operation. Profile the endpoint — usually a slow query, N+1 calls, or a blocking external API. Add indexes, caching, or async handling.
- Right-size proxy timeouts. Raise
proxy_read_timeoutonly as a stopgap; the real fix is making the upstream fast. Match timeouts across proxy, app, and LB. - Scale the upstream. Add workers/replicas if the app is simply saturated under load.
Example log line
2026/10/05 02:31:40 [error] 921#921: *9 upstream timed out (110: Connection timed out) while reading response header from upstream, upstream: "http://127.0.0.1:8000/report"How LogLens detects 504 Gateway Timeout
LogLens flags 504 bursts and ties them to the slow upstream templates and latency patterns that caused them. LogLens AI is a free, self-hosted AI log analyzer that surfaces lines like this automatically, groups them into one incident, and explains them in plain language.
Related errors
FAQ
Does raising the timeout fix a 504?
It only hides it. A higher timeout lets slow requests finish, but the real fix is making the upstream respond faster (query tuning, caching, scaling).
Is a 504 the client's fault?
No — it is a server-side timeout between the proxy and your app. The client just sees the 504.