HTTP
408 - Request Timeout
HTTP 408 Request Timeout means the server did not receive a complete request message within its timeout window.
Last reviewed: February 19, 2026|Editorial standard: source-backed technical guidance
What Does Request Timeout Mean?
The request message did not arrive completely in time, so the server abandoned processing and client workflows see latency-driven failure before application logic completes.
Common Causes
- -proxy_read_timeout is 60 seconds while upstream report generation takes about 75 seconds under cold cache.
- -Client uploads large body over unstable mobile network and stalls mid-stream until server idle timeout expires.
- -Corporate proxy handshake retries consume deadline budget so API gateway request timer elapses before origin response.
How to Fix Request Timeout
- 1Retry idempotent requests on a fresh connection because the original message may be incomplete in transit.
- 2Align client, proxy, and origin timeout budgets so request transmission can finish under expected latency.
- 3Stabilize upload path throughput and eliminate network resets before enabling aggressive retries.
Step-by-Step Diagnosis for Request Timeout
- 1Capture wire-level timing to confirm the server timed out before receiving a complete request message.
- 2Measure upload throughput, connection reuse behavior, and mid-stream resets on the failing path.
- 3Compare timeout and idle budgets across client, CDN/LB, reverse proxy, and origin service.
- 4Retest with controlled latency and packet-loss injection to reproduce the timeout boundary reliably.
Request Transmission Timing Analysis
- -Inspect whether the request body completed before server deadline (example: 12 MB upload stalls at 8 MB due to mobile network jitter).
- -Trace TCP/TLS session lifecycle for resets and half-open sockets (example: proxy closes idle keep-alive at 30s while client is still streaming).
Timeout Budget and Retry Coordination
- -Audit timeout ladder from client to origin to ensure monotonic budgets (example: origin read timeout 65s, edge idle timeout 30s, client timeout 120s).
- -Verify retry policy only retries safe operations and uses backoff with jitter (example: idempotent GET retried; non-idempotent POST guarded by idempotency key).
Implementation Examples
Reproduce HTTP 408 Request Timeoutcurl
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 408 Request Timeout
# {"error":"Request Timeout","code":"408"}Handle 408 in JavaScriptjavascript
const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 408) {
console.error('Handle 408 Request Timeout');
}Handle 408 in Pythonpython
import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 408:
print('Handle 408 Request Timeout')How to Verify the Fix
- -Re-run the failing flow and confirm complete request transmission succeeds within configured deadlines.
- -Validate timeout and retry behavior across each network hop with production-like traffic profiles.
- -Monitor connection reset rates, partial uploads, and 408 frequency for sustained stability.
How to Prevent Recurrence
- -Standardize timeout budgets and retry policies across all service boundaries.
- -Continuously probe DNS, TLS, and upstream health paths with synthetic checks.
- -Implement graceful degradation and circuit-breaking for upstream latency spikes.
Pro Tip
- -use
Expect: 100-continuefor large request bodies so clients avoid uploading payloads when the server is already likely to reject or time out the request.
Decision Support
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.