408 - Request Timeout
HTTP 408 Request Timeout means the server did not receive a complete request message within its timeout window.
Last reviewed: April 16, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Request Timeout Mean?
The server gave up before it received the full request headers or body, so the application path often never got a complete message at all. That makes 408 primarily a request-transmission or idle-connection problem, not a response-generation failure like 504.
Common Causes
- -Client uploads a large body over unstable mobile or Wi-Fi networks and stalls mid-stream until the server receive timeout expires.
- -Client reuses an idle keep-alive connection that the server or proxy already considers dead, so the next request never completes cleanly.
- -Proxy, WAF, or antivirus scanning delays request forwarding long enough that the origin read timeout fires before the full message arrives.
- -TLS renegotiation, packet loss, or flaky middleboxes pause request transmission beyond the server receive window.
- -Large request bodies are sent without resumable upload strategy,
Expect: 100-continue, or realistic read budgets.
How to Fix Request Timeout
- 1Retry the request on a fresh connection if the operation is safe to repeat, because the original message may have been incomplete in transit.
- 2Align client, CDN/LB, proxy, and origin receive or idle budgets so the full request can arrive under expected latency.
- 3Use resumable or multipart upload flows for large bodies instead of pushing one long request through unstable networks.
- 4Use
Expect: 100-continueor early validation to avoid sending large payloads down paths that will idle out anyway.
Step-by-Step Diagnosis for Request Timeout
- 1Capture wire-level timing and 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 receive, read, and idle budgets across client, CDN/LB, reverse proxy, and origin service.
- 4Check whether the same route succeeds immediately when retried on a fresh connection with the same payload.
- 5Retest with controlled latency and packet-loss injection to reproduce the timeout boundary reliably.
Seen in Production
- -Mobile clients upload media over unstable networks, stall mid-body, and the API returns 408 before the app handler ever sees a complete request.
- -Browsers reuse a keep-alive connection that an edge or origin has already marked idle, so the next request gets a 408 immediately on the stale socket.
- -A WAF or proxy buffers request bodies for inspection and delays forwarding long enough that the origin receive timeout fires first.
- -Large multipart form uploads fail only on one corporate network because a middlebox pauses TLS sessions mid-stream and the server abandons the incomplete request.
Request Completion Audit
- -Inspect whether the request body completed before the server deadline (example: 12 MB upload stalls at 8 MB due to mobile network jitter).
- -Capture bytes received, time-to-first-byte from the client, and the exact point where transmission stopped (example: headers arrive, body stalls, then server logs 408).
Connection Reuse and Idle Budget Checks
- -Trace TCP/TLS session lifecycle for resets, stale keep-alives, and half-open sockets (example: proxy closes idle keep-alive at 30s while client still tries to reuse it).
- -Audit receive and idle budgets from client to origin to ensure request transmission can complete end to end (example: origin read timeout 65s, edge idle timeout 30s, client upload path 90s).
Decision Shortcut: Slow Upload vs Idle Keep-Alive
- -If the request fails only for large bodies or poor networks, prioritize upload throughput and body-completion evidence before debugging backend latency.
- -If a fast retry on a new TCP connection succeeds immediately, suspect stale keep-alive reuse or idle timeout drift more than application response time.
Wrong Fix to Avoid
- -Do not treat 408 like a generic upstream timeout and start tuning backend response budgets first.
- -Do not blindly retry non-repeatable writes unless you have idempotency protection and evidence the original request never completed.
- -Do not raise every timeout globally before proving which hop abandoned the incomplete request.
Implementation Examples
2026-04-15T12:05:18Z edge=api-gateway requestId=req_2a61e4
bytesReceived=8388608 expectedBytes=12582912 status=408
message="client request body timeout while reading upstream request body"curl --http1.1 --expect100-timeout 2 \
-H 'Expect: 100-continue' \
--data-binary @large.bin \
https://api.example.com/uploadsclient_header_timeout 15s;
client_body_timeout 60s;
keepalive_timeout 30s;Incident Timeline
12:03 UTC
The client starts a request but does not finish sending it cleanly
Signal: A large upload, stale keep-alive reuse, or network stall begins before the full request headers or body reach the server.
Why it matters: At this stage the key question is whether the server ever received a complete request message at all.
12:04 UTC
A server, proxy, or edge tier waits for more bytes that never arrive in time
Signal: Receive or idle timeout counters tick upward while body bytes stop progressing or the connection remains half-open.
Why it matters: This is 408 territory: request-transmission failure, not slow application response generation.
12:05 UTC
The server abandons the incomplete request and closes or resets the connection
Signal: Client sees 408 or a closed socket, and origin logs show timeout before full request completion.
Why it matters: The application may never have seen a complete body, so recovery should start with the connection and upload path.
12:07 UTC
A fresh connection or resumable path completes the request successfully
Signal: The same operation succeeds when retried on a new socket, with smaller chunks, or with corrected idle budgets.
Why it matters: That confirms the incident lived in request transmission or connection reuse, not in business logic.
Seen in Production
Large client uploads fail on unstable last-mile networks
Frequency: common
Example: Mobile users uploading media hit 408 after packet loss slows transfer below the server read timeout.
Fix: Adopt resumable uploads, tune read deadlines, and split large payloads into restartable chunks.
Stale keep-alive reuse creates immediate request timeout failures
Frequency: common
Example: Browser or SDK reuses a connection the edge already marked idle, and the next request gets a 408 before the body can complete.
Fix: Tune keep-alive symmetry and force retries onto fresh sockets after idle-connection failures.
Security proxy buffering delays request forwarding
Frequency: medium
Example: A proxy scans or buffers upload bodies so long that the origin times out waiting for the complete message.
Fix: Reduce buffering delay, increase only the right receive budget, or bypass deep inspection for approved large-upload paths.
Wrong Fix vs Better Fix
Raise backend timeouts vs prove incomplete request receipt
Wrong fix: Tune origin processing timeouts because the request “timed out.”
Better fix: Prove whether the server ever received a complete request message before changing response-generation budgets.
Why this is better: A 408 often means the app never got a full request. Backend handler tuning does not fix a stalled upload or dead keep-alive.
Retry on the same socket vs retry on a fresh connection
Wrong fix: Resend the request over the same suspect connection and hope it clears.
Better fix: Open a fresh connection and only repeat the request when the operation is safe to retry.
Why this is better: Stale keep-alive and half-open connections often recreate the same 408 immediately unless the transport path is reset.
Ship one giant body vs use resumable or staged transfer
Wrong fix: Push large uploads through one long request on weak networks and only increase idle budgets.
Better fix: Use multipart, resumable upload, or Expect: 100-continue so incomplete transmission does not force whole-request restarts.
Why this is better: Breaking the transfer into recoverable steps reduces 408 risk and makes failures cheaper to recover from.
Debugging Tools
- -Raw request-byte and body-progress logs
- -Connection reuse and keep-alive telemetry
- -Edge and origin receive-timeout metrics
- -Packet capture or synthetic upload probes
How to Verify the Fix
- -Re-run the failing flow and confirm complete request transmission succeeds within configured receive and idle budgets.
- -Validate retries occur on fresh connections where appropriate and that non-repeatable writes remain protected.
- -Monitor partial uploads, connection resets, stale keep-alive reuse, and 408 frequency for sustained stability.
How to Prevent Recurrence
- -Standardize receive, idle, and keep-alive budgets across clients, proxies, and origins.
- -Prefer resumable or multipart uploads for large bodies over long single-shot requests.
- -Continuously monitor partial request completion, connection reuse failures, and network resets by route.
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.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.