408 Request Timeout
The server gave up waiting for the client to finish sending the request.
Status
HTTP/1.1 408 Request Timeout
Details
- Category: 4xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.5.9
- Cacheable: Not cacheable
- Response body: Allowed
- Retry: Safe to retry
408 is about the request, not the response. The server opened a connection, waited for a complete request, and the client did not send one in time. Servers also use it to reap idle keep-alive connections, sending 408 and closing rather than holding sockets open indefinitely.
The distinction from 504 matters when debugging: 408 means the client was too slow, 504 means an upstream server was. A 408 on a large upload usually means the connection is too slow for the configured body timeout.
Headers
- Connection: Usually close. The server is terminating the connection along with the response.
Common causes
- An idle keep-alive connection was reclaimed by the server.
- A slow or interrupted upload exceeded the server's request body timeout.
- A client opened a connection and sent headers but never completed the request.
- Packet loss or high latency on the path stretching the request beyond the timeout.
How to fix it
As the client
- Retry the request. 408 explicitly allows it, and a fresh connection often succeeds immediately.
- Send the body promptly after the headers rather than opening the connection early.
- Chunk large uploads, or raise client-side socket timeouts to match the size of what you are sending.
As the server
- Set request timeouts that reflect real client conditions, especially for upload endpoints.
- Send Connection: close with the 408 so clients do not reuse a socket the server has abandoned.
Examples
POST /upload HTTP/1.1 Host: api.example.com Content-Length: 5242880 (client stalls mid-body) HTTP/1.1 408 Request Timeout Connection: close
Notes for proxy users
Through a proxy, a 408 can come from the proxy or from the origin, and the two look identical to the client. If retries through the same endpoint keep timing out while direct requests do not, test the proxy connection on its own before changing application timeouts.