Error guide

504 Gateway Timeout

A proxy waited for your application and gave up — the upstream was reachable, just too slow.

A 504 Gateway Timeout means a proxy forwarded the request upstream, waited for its configured timeout, and gave up before an answer arrived. The crucial difference from a 502 is that the upstream was reachable: the connection was made, the request was delivered, and the response was simply too slow.

So this is a latency problem, not an availability one, and it usually points at something the application is waiting on rather than at the application itself — a slow query, an unresponsive third-party API, a lock, an exhausted connection pool where requests queue before any work begins.

The reflex is to raise the timeout, and it is usually the wrong move. A longer timeout converts a fast failure into a slow one and holds connections open on every hop while doing it, which makes an overload worse. The timeout is what surfaced the problem, not what caused it.

Common causes

  • A slow database query, often one that lost an index or is now scanning a much larger table.
  • A third-party API that is slow or unresponsive, called synchronously in the request path.
  • Connection-pool exhaustion, where requests queue before doing any work.
  • Lock contention or a long-running transaction blocking others.
  • Work that belongs in a background job being done inside the request.
  • A proxy timeout shorter than a legitimately long operation such as a report or an export.

How to diagnose it

  1. Check upstream response times: a 504 is the tail of a latency distribution crossing the timeout, so the trend precedes it.
  2. Find which requests time out — if it is one endpoint, look at what that endpoint waits on.
  3. Check every dependency's own latency, not just its availability; a slow dependency is invisible to an up/down check.
  4. Look at pool saturation and queue depth, which explain a whole-service 504 better than any single slow call.
  5. Compare the timeouts along the chain: CDN, load balancer, proxy, application. The shortest one produces the 504.

Whose fault is it? The server's side

Server-side, and frequently caused by a dependency rather than by your own code — which is still your incident, because your users are the ones waiting.

What monitoring sees

A monitor sees a 504 as a plain failed check, so the code alone does not tell you it was slowness rather than absence. What does is response-time monitoring: Uptimely records response time on every check and monitor criteria can raise an alert on a response-time threshold, which fires during the degradation that precedes the 504s rather than after it.

Related error guides

Terms used on this page

Questions

Should I increase the gateway timeout to fix 504s?

Rarely. A longer timeout turns a fast failure into a slow one and holds connections open on every hop, which makes overload worse. Fix what is slow, or move it out of the request path.

How do I catch 504s before they happen?

Alert on response time, not only on availability. A 504 is latency crossing a timeout, so the rise is visible in your check history minutes before anything starts failing.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.