HTTP 408 Request Timeout: Why the Server Gave Up Waiting

Aug 03, 2026 · HTTP Status Codes

Here's the thing most people get backwards about the 408 status code: it's not the server telling you it's slow. It's the server telling you that you — or rather, your client — were too slow. The connection opened, the server allocated a worker and started a timer, and the full request never arrived before that timer expired. So the server hung up.

That inversion matters, because if you treat a 408 like a 504 and start profiling your application code, you'll waste an afternoon looking in the wrong place. The app never saw the request. The timeout fired at the edge, before a single line of your code ran.

What a 408 status code actually tells you

Every web server keeps a budget for how long it will wait between accepting a TCP connection and receiving a complete HTTP request — headers, and body if there is one. In nginx that budget is controlled by client_header_timeout and client_body_timeout (both default to 60 seconds). Apache has RequestReadTimeout. When the clock runs out mid-request, the server responds with 408 and closes the connection.

The formal definition in RFC 9110 says the server "did not receive a complete request message within the time that it was prepared to wait." Note the phrasing: prepared to wait. This is a policy decision by the server operator, not a hard failure. Two servers with different timeout settings can give the same client two different outcomes.

Where the timeout fires in the request path

Picture the path a request takes: browser, then maybe a CDN, then a reverse proxy or load balancer, then the application server. A 408 is almost always generated by the first server-side hop that terminates the client's TCP connection — usually the CDN edge or the front proxy. Anything behind that point never gets involved, because the request was never complete enough to forward.

That's a useful diagnostic fact. If you're seeing 408s in your CDN logs but nothing in your nginx access logs, the edge gave up before forwarding. If they show up in nginx's logs, look at the connection between the client and nginx specifically.

Common causes worth checking first

• Flaky client networks. Mobile users on the edge of coverage start an upload, stall, and the server times out. If your 408 rate correlates with mobile traffic or specific geographies, this is likely it. Not much to fix server-side beyond a reasonable body timeout.
• Large uploads against tight timeouts. A 50 MB file upload over a slow uplink can easily exceed a 60-second body timeout. If your app accepts big files, the upload endpoint needs a more generous client_body_timeout than the rest of the site.
• Speculative connections. Browsers open TCP connections ahead of time (preconnect) and sometimes never send a request on them. Some servers log the resulting cleanup as 408. These are harmless noise — check whether the "requests" have zero bytes received.
• Broken keep-alive handling. A client reuses an idle connection at the exact moment the server closes it. Well-behaved clients retry transparently; buggy ones surface the 408 to the user.
• Slowloris-style abuse. Attackers deliberately send headers one byte at a time to tie up workers. Here 408 is your defense working as intended, and you want the timeout tighter, not looser.

How to reproduce and diagnose a 408

You can trigger one on demand by opening a connection and sending nothing. With netcat: connect via nc yoursite.com 80, type half a request line, and wait. When the header timeout expires you'll see the 408 come back. To test body timeouts, curl lets you throttle the upload: curl -X POST --limit-rate 1k -d @bigfile.bin https://yoursite.com/upload simulates a slow client pushing a body at 1 KB/s.

On the log side, the signature of a genuine client stall is a 408 entry with an unusually long request time and fewer bytes received than the Content-Length the client declared. In nginx, log $request_time and $request_length and the pattern jumps out. A burst of 408s from a single IP with tiny request lengths is the Slowloris signature instead.

One thing worth ruling out: if response times across the whole site have been creeping up, clients on marginal connections hit timeouts more often as a side effect. It's worth understanding what server response time is made of before assuming the 408s are purely a client problem.

Does HTTP 408 hurt your SEO?

Googlebot fetches from fast, well-connected infrastructure, so it almost never triggers a 408 the way a phone on 3G does. But if your server is so overloaded that it can't read requests promptly and starts timing out even fast clients, Googlebot will see errors — and Google treats sustained 4xx/5xx server trouble as a signal to slow its crawl rate. Occasional 408s are a non-issue for rankings. A spike of them is usually a symptom of a deeper capacity problem that will matter, because the same overload produces 500s and 503s that Google takes seriously. If you're seeing 408 alongside 503 errors, treat the capacity issue as the real incident.

Tuning timeouts without breaking slow clients

The temptation after a 408 incident is to crank every timeout to 300 seconds. Resist it. Long timeouts mean each stalled connection holds a worker (or at least a file descriptor and buffer memory) for longer, which lowers the concurrency ceiling and makes you softer against slow-request attacks. The better approach:

1. Keep the default header timeout tight — 10 to 30 seconds is plenty. Legitimate clients send headers in milliseconds.
2. Give body timeouts room only on routes that need it: upload endpoints, webhook receivers accepting large payloads.
3. Let your CDN absorb slow clients. Most CDNs buffer the full request at the edge and only forward it to your origin once complete, which means your origin's timeouts almost never fire against real users.
4. Rate-limit by IP so one misbehaving client can't hold dozens of connections open simultaneously.

Finally, make sure you'd actually notice a 408 spike. These errors are invisible in most dashboards because they never reach the application layer — they live only in edge and proxy logs. Set up uptime monitoring that checks your site from outside your own network, and alert on the 408 count in your front proxy's logs, not just on application errors. The whole point of a 408 is that your app never heard about it; your monitoring needs to listen somewhere your app can't.