408 Request Timeout 4xx

What does 408 mean?

A 408 Request Timeout response means the server was waiting for the client to send a complete request, but the client took too long — so the server gave up and closed the connection. This is fundamentally different from 504 (Gateway Timeout), which is about a proxy waiting too long for a response from an upstream server. 408 is about the origin server itself waiting too long for the request to even finish arriving.

408 is relatively uncommon in typical web usage — most requests are small and complete almost instantly. It becomes more relevant with slow or unreliable client connections, very large request bodies (file uploads), or deliberately slow/malicious clients.

How a 408 behaves

• The server may close the connection after sending a 408, since the client appears unresponsive
• It can carry a body, though often minimal — there's limited value in elaborate explanations for a timeout
• It's not cacheable — represents a connection-specific timing issue
• Some servers send it proactively to close idle connections, even if the client hasn't technically "failed" — it's partly a server resource-management mechanism

Common causes

If you're building/operating the server:

• Your server has a configured timeout for how long it'll wait to receive a complete request, and clients with slow connections (or very large uploads) are exceeding it
• A reverse proxy or load balancer in front of your application has its own request-timeout settings that may differ from the application server's

If you're calling an API:

• You're uploading a large file over a slow connection, and the upload is taking longer than the server's configured request timeout
• A client library is sending the request body in unusually small chunks with delays between them, causing the overall request to exceed the timeout even though the total data isn't that large
• A network issue is causing the request to be sent very slowly or with interruptions

If you're a website visitor:

• You're on a slow or unstable connection (e.g., poor mobile signal) attempting to upload a file or submit a large form, and the upload doesn't complete within the server's patience window
• Your browser opened a connection to the server but didn't send the request promptly — rare in normal browsing, more relevant to scripts/automated clients with bugs

How to fix it

As an API/website builder:

• Set reasonable request-timeout values that account for realistic upload scenarios on your platform — if users commonly upload large files, ensure timeouts (at every layer: web server, reverse proxy, load balancer) accommodate slower connections
• For large file uploads, consider chunked/resumable upload patterns (where the file is sent in pieces, each within a reasonable individual timeout) rather than one long single request
• Don't set request timeouts so generously that slow/malicious clients can hold connections open indefinitely, tying up server resources — there's a balance between accommodating legitimate slow uploads and protecting against abuse

As an API consumer:

• For large uploads, check if the API supports chunked or resumable uploads instead of a single large request
• Ensure your HTTP client isn't introducing unnecessary delays while sending the request body (e.g., due to inefficient streaming implementations)
• On unreliable connections, consider implementing retry logic specifically for 408s, potentially with a smaller payload or chunked approach on retry

As a website visitor:

• Try on a more stable connection (Wi-Fi instead of cellular, for instance) if uploading large files
• Break large uploads into smaller pieces if the site supports it (e.g., uploading fewer files at once)

408 vs 504

Real-world examples

Web servers commonly use request-timeout settings (sometimes called client_body_timeout or similar, depending on the server software) specifically to protect against slow-client attacks, where a malicious client deliberately sends a request very slowly to tie up server connections — 408 (or simply closing the connection) is part of the defense against this pattern. Large file upload features in web applications often need to account for 408s on slower connections, sometimes implementing client-side chunking specifically to keep each individual request well within typical timeout windows.

SEO implications

408 is essentially irrelevant to page-level SEO — search engine crawlers send small, fast requests (GET requests for pages) that virtually never approach request-timeout thresholds designed around upload scenarios.

FAQ

What's the difference between 408 and 504?

408 is about the server waiting too long to receive a request from the client. 504 is about a proxy waiting too long to receive a response from an upstream server after forwarding a request. They involve waiting in opposite "directions" of the request/response cycle.

Why would I get a 408 on a small request?

It's unusual, but possible if there's a significant delay between establishing the connection and actually sending the request data — some servers proactively timeout idle connections this way, partly as a defense against slow-client style attacks.

Does 408 mean my data wasn't received at all?

It means the server gave up waiting for the complete request — partial data may have been received but discarded, since an incomplete request can't be processed. You'd need to resend the complete request.

Can large file uploads avoid 408 entirely?

Using chunked or resumable upload protocols — where a large file is broken into smaller pieces, each sent and acknowledged within its own timeout window — is the standard way to avoid request timeouts on large uploads, rather than relying on one very long single request.

Is 408 something users commonly see?

Rarely in normal browsing. It's more likely to be encountered by developers testing upload functionality on slow/throttled connections, or in automated systems sending requests over unreliable networks.

Fun fact

408 is one of the few status codes that exists partly as a defensive mechanism rather than purely a descriptive one — by giving servers an explicit, standardized way to say "I've waited long enough, goodbye," it provides a building block for protecting against connection-exhaustion attacks where malicious clients try to hold open many slow connections simultaneously.