HTTP 408 Request Timeout is the mirror image of the timeout most people know. A 504 means the server waited too long for something behind it; a 408 means the server waited too long for you — your request started arriving and then stalled before it finished.
What actually happened ¶
The client opened a connection and began sending a request, but did not complete it within the server's idle timeout. The server closed the connection and, if it was feeling polite, sent a 408 first. Many servers skip the courtesy and just close, which is why you see connection resets far more often than you see 408s.
Why it is rare, and what it means when it isn't ¶
Modern browsers on decent connections finish sending a request in milliseconds. A 408 therefore usually indicates one of:
- A genuinely poor connection — high packet loss on mobile or congested Wi-Fi, where a large upload stalls mid-flight.
- A large file upload hitting a server whose timeout was tuned for small requests.
- A pre-opened connection that went unused. Browsers speculatively open connections; if one sits idle past the server's timeout, some servers emit a 408 on it. This is harmless, invisible, and the most common 408 in the wild.
- A proxy or scanner holding connections open without sending anything.
408 vs 504 vs 524 ¶
| Code | Who ran out of patience | Waiting for |
|---|---|---|
| 408 | The origin server | Your request to finish arriving |
| 504 | A gateway or proxy | The upstream server to reply |
| 524 | Cloudflare | The origin to reply within 100s |
| ERR_CONNECTION_TIMED_OUT | Your browser | The connection to open at all |
If you are seeing it as a user ¶
Retry first — a 408 is explicitly retryable and often succeeds immediately. If it persists, the connection between you and the site is the suspect: try a different network, and note whether large uploads specifically are what fail. A site that 408s you while answering probes from elsewhere is not down.
If you run the server ¶
Check whether your request-timeout window is tuned for the payloads you actually accept. A 30-second limit is generous for a form post and hostile to a 200MB upload from a phone on cellular. Raise it for upload endpoints specifically rather than globally, and make sure the limit at your proxy is not shorter than the one at your application.
What to look for in the logs ¶
408s cluster, and the shape of the cluster tells you the cause. If they are spread evenly across clients and paths, look at speculative connections — harmless, and usually not worth chasing. If they concentrate on one endpoint, that endpoint accepts something big and your timeout is tuned for something small. If they concentrate on a handful of client addresses, you are looking at either bad connections or something scanning you.
Note that many servers do not log 408s at the application level at all, because the request never completed and there is nothing for the application to see. The evidence lives in the web server's own access log, not in your framework's.
The scanner case ¶
A recognisable pattern is a steady trickle of 408s from addresses that never complete a request. That is usually automated scanning: connections opened to see what answers, then abandoned. It is noise rather than an attack, and the correct response is to ignore it — tightening the timeout to cut it off tends to catch real users on poor connections first.
FAQ ¶
Is a 408 error my fault or the website's?
Most often the network in between. The server is clearly running — it responded — and your client tried. Retrying, then switching networks, isolates it quickly.
Should I retry after a 408?
Yes. It is one of the few status codes that explicitly invites a retry, and the connection is closed afterwards so a fresh one is expected.