408 Request Timeout

The HTTP 408 Request Timeout status code is a client error returned by the server to indicate a request is arriving too slowly and the server is unwilling to wait for completion, terminating the connection.

Table of Contents

Usage

When a 408 Request Timeout error arrives, the client has initiated a request but for some reason has not transmitted the full payload. This occurs when an internet connection is slow or has dropped. The response includes the Connection header specifying the connection has been closed.

Upon receiving the Connection: close header, the client attempts the request again.

SEO impact

Search engines like Google do not index a URL returning a 408 status. Previously indexed URLs returning this status code are removed from search results.

Example

The client begins sending a 10K PDF file to the server, but the connection suffers from intermittent connectivity issues and the server concludes the transmission is too slow. The server cancels the request and closes the connection. When the connection stabilizes, the client retransmits the file successfully.

Initial request

PUT /docs HTTP/1.1
Host: www.example.re
Content-Type: application/pdf
Content-Length: 10000

Initial response

HTTP/1.1 408 Request Timeout
Connection: Close
Content-Type: text/html
Content-Length: 198

<html>
  <head>
    <title>Connection Close</title>
  </head>
  <body>
    <p>The transmission was not received quickly
    enough. Check connectivity and try again.</p>
  </body>
</html>

Next request

PUT /docs HTTP/1.1
Host: www.example.re
Content-Type: application/pdf
Content-Length: 10000

<File transfer successful for PDF file>

Final response

HTTP/1.1 200 OK

How to fix

A 408 Request Timeout means the server closed the connection because the client did not complete the request in time.

  1. Check network connectivity and latency. An unstable or slow connection delays request transmission. Run ping and traceroute to the server to identify packet loss or high latency hops. Confirm the connection is stable before retrying.

  2. Reduce payload size or split large uploads. Sending a large file over a slow connection exceeds the server's patience. Compress the payload, use chunked Transfer-Encoding, or break the upload into smaller parts using multipart upload APIs.

  3. Increase client-side timeout settings. The HTTP client library or browser enforces its own timeout. Raise the connection and read timeout values to accommodate slower transfers. In curl, use --connect-timeout and --max-time. In Python requests, set timeout=(connect, read).

  4. Verify the server's timeout configuration. Adjust timeout directives based on the web server:

    nginx:

    client_header_timeout 60s;
client_body_timeout 60s;
keepalive_timeout 75s;
send_timeout 60s;

    Apache:

    Timeout 60
KeepAliveTimeout 5
RequestReadTimeout header=20-40 body=20

    The RequestReadTimeout directive (mod_reqtimeout) controls header and body read timeouts separately. Increase these values when clients legitimately need more time.

  5. Adjust Keep-Alive settings. A low keepalive_timeout closes idle connections before the client sends the next request in a persistent connection. In nginx, the default keepalive_timeout is 75 seconds. Raise the value for APIs serving clients with bursty request patterns. In Apache, increase KeepAliveTimeout (default 5 seconds) and verify MaxKeepAliveRequests allows enough requests per connection.

  6. Check reverse proxy and load balancer timeouts. When a reverse proxy (nginx, HAProxy, AWS ELB) sits in front of the application server, each layer enforces its own timeout. The proxy closes the connection first if its timeout is shorter than the backend. In nginx reverse proxy mode:

    proxy_connect_timeout 60s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

    AWS ALB has a default idle timeout of 60 seconds, configurable in the load balancer attributes.

  7. Retry the request. A 408 is often transient. Re-establish the connection and resubmit the full request. Implement automatic retry logic with exponential backoff for programmatic clients. The Retry-After header, when present, specifies how long to wait before retrying.

  8. Review server error logs. nginx logs timeout events in the error log. Apache logs mod_reqtimeout violations. Check /var/log/nginx/error.log or /var/log/apache2/error.log for entries matching the request timestamp to identify whether the header or body read timed out.

Code references

.NET

HttpStatusCode.RequestTimeout

Rust

http::StatusCode::REQUEST_TIMEOUT

Rails

:request_timeout

Go

http.StatusRequestTimeout

Symfony

Response::HTTP_REQUEST_TIMEOUT

Python3.5+

http.HTTPStatus.REQUEST_TIMEOUT

Java

java.net.HttpURLConnection.HTTP_CLIENT_TIMEOUT

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_REQUEST_TIMEOUT

Angular

@angular/common/http/HttpStatusCode.RequestTimeout

Takeaway

The 408 Request Timeout status code is a client error the server sends when an HTTP request takes too long to complete. Common causes include slow or broken internet connections. Once connectivity is restored, the client retries the request.

See also

Last updated: March 5, 2026