<!-- 504 Gateway Timeout: causes and fixes — Uptimely -->
> Markdown version of https://getuptimely.com/errors/504 — the page itself is the canonical copy.

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

- [5xx server errors](https://getuptimely.com/errors/5xx)
- [502 Bad Gateway](https://getuptimely.com/errors/502)
- [408 Request Timeout](https://getuptimely.com/errors/408)
- [Connection timeout (ETIMEDOUT)](https://getuptimely.com/errors/connection-timeout)
- [499 Client Closed Request](https://getuptimely.com/errors/499)

## Terms used on this page

- [Response time](https://getuptimely.com/glossary/response-time)
- [Degraded performance](https://getuptimely.com/glossary/degraded-performance)
- [Mean time to detect (MTTD)](https://getuptimely.com/glossary/mttd)
- [Failure threshold](https://getuptimely.com/glossary/failure-threshold)

## 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](https://getuptimely.com/errors), 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**.
