Error guide
408 Request Timeout
The server gave up waiting for the client to finish sending its request.
A server sends a 408 when the client took too long to send its request. The connection was open, the server waited for the request line, headers or body to arrive, and it closed the connection when its read timeout ran out. Note the direction. A 408 is about the request arriving too slowly, not about the response being produced too slowly.
That is what separates it from the timeouts it gets confused with. A client-side timeout is the client giving up on the server, and it has no status code at all, only an error from the client library. A 504 comes from a gateway or proxy that received the request, passed it upstream, and got no answer in time. A 524 is Cloudflare's version of that: it reached your origin and sent the request, and got no HTTP response within 125 seconds.
Most 408s in real logs are harmless. Servers keep idle keep-alive connections open for reuse and close them after a while, and some servers and proxies log that closure as a 408 even though nothing failed and no user noticed. A steady low rate is normal. The 408s that mean something come in bursts, and they usually point at a network problem or at a client sending a large body more slowly than the server's timeout allows.
Common causes
- Idle keep-alive connections being closed and logged as 408s. This is usually harmless.
- A client on a slow or lossy link taking too long to send a request body.
- Large uploads exceeding a request-read timeout sized for small requests.
- Packet loss or a stalled connection between the client and the server.
- A proxy with a shorter read timeout than the server, closing connections mid-request.
How to diagnose it
- Check whether the rate is a steady background level or a burst. The first is normal, the second is not.
- See whether the affected requests carry bodies, and how large. Read timeouts hit uploads first.
- Compare the request-read timeout on each hop. The shortest one wins, and it is rarely the one you set.
- Correlate a burst with network events rather than with deploys.
- Check whether the clients seeing it share a network path or a mobile carrier.
Whose fault is it? It depends which layer
Formally a client error, but the network causes it as often as the client does. Sometimes the real cause is a server read timeout that is too short for the request bodies it receives.
What monitoring sees
A server 408 falls outside the 200 to 399 range an Uptimely check accepts by default, so the check fails and the 408 is recorded with it. Uptimely's own timeout is a different thing. A check waits 30 seconds by default, and Website and API monitors can set anything from 1 to 60 seconds. When that runs out, the check records a timeout failure with no status code, not a 408. Either way, a failure that would make the monitor's status worse is checked a second time before it counts, and by default an incident is declared only after two failed checks in a row.
Related error guides
Terms used on this page
Questions
Is 408 a 4xx or a 5xx error?
A 408 is a 4xx error, a client error. The server is saying it timed out waiting for the client to send its request, so the request is what was slow, not the server's handling of it. The timeout most people expect to be a 5xx is the 504 Gateway Timeout, which is a server error: a gateway passed the request upstream and the upstream did not answer in time. See the 4xx and 5xx guides for how the two classes differ.
What is the difference between a 408, a 504 and a 524?
A 408 means the server gave up waiting for the client to send its request. A 504 means a gateway passed the request upstream and the upstream did not answer in time. A 524 means Cloudflare waited more than 125 seconds for your origin to respond. The first is about the request arriving, the other two are about the response.
Does a monitor report a 408 when it times out?
No. When a monitor gives up waiting, that is a client-side timeout, and it has no status code. An Uptimely check records it as a timeout failure. A 408 appears only when the server itself sends one, and then the check fails with the 408 recorded.
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.