Timeouts are among the most common errors encountered in web applications, but determining who timed out on which network hop is critical for resolving them.

Two standard status codes address timeouts in HTTP: HTTP 408 Request Timeout and HTTP 504 Gateway Timeout.

Core distinction: client transmission versus backend latency

The distinction depends entirely on which direction timed out:

  • HTTP 408 Request Timeout (4xx Client Error): The server was waiting for the client to send request data, but the client was too slow or left the connection idle.
  • HTTP 504 Gateway Timeout (5xx Server Error): An edge proxy or gateway was waiting for the upstream backend service to process and reply, but the backend took too long.

What HTTP 408 means

According to RFC 9110, an HTTP 408 status indicates that the server did not receive a complete request message within the time that it was prepared to wait.

Common causes of a 408 response:

  • The client established a connection, sent initial headers, but paused mid-stream while uploading a large body.
  • Severe client-side uplink latency or packet drops.
  • Web servers (such as Apache or NGINX) closing idle persistent keep-alive connections that sat inactive for too long.
HTTP/1.1 408 Request Timeout
Connection: close
Content-Type: text/plain

Request Timeout: Server closed idle connection.

What HTTP 504 means

An HTTP 504 status indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server.

Common causes of a 504 response:

  • The client dispatched its request completely and promptly.
  • The reverse proxy forwarded the request to the upstream backend.
  • The backend hung on a slow database query, external API, or computation, exceeding the proxy’s read timeout limit.
HTTP/1.1 504 Gateway Timeout
Via: 1.1 gateway.example.test
Content-Type: application/json

{"error": "gateway_timeout", "message": "Upstream service did not reply in time."}

Server waiting for request vs. gateway waiting for upstream

Visualizing the two timeout locations clarifies the difference:

[Client] ===== (Hop 1: Incomplete Request / Idle) =====> [Server]  ===> 408 Request Timeout

[Client] ----> [Proxy] ===== (Hop 2: Waiting on Upstream) =====> [Backend] ===> 504 Gateway Timeout
  1. In 408: The problem is upstream of the server (the client or client connection).
  2. In 504: The problem is downstream of the proxy (the backend application or database).

Practical comparison table

Dimension HTTP 408 Request Timeout HTTP 504 Gateway Timeout
Error Class 4xx (Client Error) 5xx (Server Error)
Culprit Node Client / Client Network Connection Upstream Backend Application / Database
Request Transmission Incomplete or stalled request body Fully transmitted; backend too slow
Idle Connection Teardown Yes (servers use 408 to close idle sockets) No (504 indicates active request execution)
Where to Debug Client network, upload streams, keep-alive Database queries, microservice latency

Retry and request safety considerations

When handling timeouts, retry logic must consider HTTP method idempotency:

  • Safe to retry (Idempotent): GET, HEAD, PUT, DELETE. If a 504 or 408 occurs, repeating the request will not produce unintended duplicate records.
  • Caution required (Non-idempotent): POST requests. If a 504 occurs on a POST, the upstream backend may have processed the database write before the proxy timed out. Retrying blindly could result in duplicate charges or duplicate rows. Use idempotency keys where supported.

What to check before changing code

  1. Check the status class: 408 points to client upload latency or idle sockets; 504 points to slow backend processing.
  2. Review request upload behavior: For 408 errors, verify chunked transfer encoding and upload streaming health.
  3. Trace backend execution: For 504 errors, check database query execution times and microservice call durations.

Key takeaway

HTTP 408 means the server timed out waiting for the client to finish sending its request. HTTP 504 means a proxy timed out waiting for a backend server to produce a response.