RequestTimeout
Amazon S3 RequestTimeout means the request connection or body transfer did not progress quickly enough for S3 to continue processing it.
Last reviewed: April 27, 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?
S3 did not receive the request body or transfer progress within the expected window. The root cause is usually outside S3: slow source generation, blocked streams, unstable networks, proxy idle limits, single-part uploads that are too large, or SDK timeout settings that do not match the transfer pattern.
Common Causes
- -Application streams data from a slow producer, such as a database export, compression job, or remote fetch, and the upload body stalls.
- -Large single-part
PutObjectuploads run over unstable mobile, corporate proxy, or long-distance network paths. - -Proxy, load balancer, firewall, or NAT idle timeout closes the connection before the request body completes.
- -SDK request, socket, or connection timeout settings are too short for the transfer profile.
- -Multipart upload threshold is too high, so large files are not split into independently retryable parts.
How to Fix Request Timeout
- 1Switch large uploads to multipart upload or SDK transfer manager so failed parts can retry independently.
- 2Buffer slow producer output to disk/object chunks before sending to S3 instead of streaming directly from a slow source.
- 3Measure throughput and idle gaps between producer, client, proxy, and S3 request logs.
- 4Tune SDK request/socket timeouts and proxy idle timeouts to match expected part upload duration.
- 5For globally distributed clients, test direct presigned multipart upload and Transfer Acceleration before routing through your app server.
Step-by-Step Diagnosis for Request Timeout
- 1Capture bucket, key, operation, object size, transfer duration, request ID, SDK retry attempt, and client region/network path.
- 2Compare source read timing, upload stream write timing, and S3/server access log duration for the same request.
- 3Identify whether failures cluster by file size, geography, proxy path, mobile network, runtime, or source generator.
- 4Check whether uploads use multipart and what part size/concurrency settings are active.
- 5Inspect proxy/firewall/NAT logs for idle close or upstream timeout before S3 returns the error.
Seen in Production
- -A CSV export streams rows from a slow database directly into
PutObject; the database pauses and S3 times out the body transfer. - -A mobile client uploads a 700 MB video through a presigned URL over a lossy connection without multipart resume.
- -A corporate proxy closes idle upstream connections while a compression process pauses between chunks.
- -A Lambda function generates a large ZIP on the fly and starves the outbound S3 stream during CPU-heavy compression.
Producer, Network, and Proxy Boundary
- -Trace whether bytes stop at the source generator, client socket, proxy, or S3 request boundary.
- -Compare timeout values across SDK, HTTP agent, proxy, load balancer, and firewall layers.
Multipart and Retry Design
- -Use multipart for large or unreliable uploads so retries operate on bounded parts.
- -Persist multipart state when uploads can outlive a single process or network session.
Decision Shortcut: Slow Producer vs Slow Network
- -If source read gaps appear before bytes reach the socket, buffer or chunk the producer output.
- -If socket writes continue but S3/proxy closes the connection, inspect network path and timeout settings.
- -If only large files fail, lower multipart threshold and tune part size/concurrency.
Wrong Fix to Avoid
- -Do not only increase retry count if each retry restarts a huge single-part upload from byte zero.
- -Do not blame S3 availability before proving where the byte stream went idle.
- -Do not stream slow generated content directly to S3 without backpressure and buffering controls.
Implementation Examples
2026-04-27T02:15:18Z bucket=exports-prod key=reports/full-export.csv
operation=PutObject sizeBytes=1184920012 idleMs=42000 status=400 error=RequestTimeout
source=db-export proxy=corp-egress requestId=2AX8Q1HD9X7J4P2Kimport { S3Client } from "@aws-sdk/client-s3";
import { Upload } from "@aws-sdk/lib-storage";
const parallelUploads3 = new Upload({
client: new S3Client({}),
params: { Bucket: "exports-prod", Key: "reports/full-export.csv", Body: bufferedStream },
queueSize: 4,
partSize: 16 * 1024 * 1024,
leavePartsOnError: false,
});
await parallelUploads3.done();aws s3 cp large-file.bin s3://exports-prod/reports/full-export.csv --debug
# Compare SDK retries, request IDs, and transfer gaps with proxy/S3 logs.Incident Timeline
02:11 UTC
Upload starts with a slow or fragile transfer path
Signal: Large object upload begins from generated content, mobile client, proxy path, or single-part request.
Why it matters: The transfer will fail if bytes stop flowing for too long.
02:14 UTC
Producer or network stalls mid-request
Signal: Database, compressor, HTTP proxy, mobile network, or SDK socket stops delivering body bytes.
Why it matters: The timeout clock is now driven by transfer inactivity, not object semantics.
02:15 UTC
Client receives RequestTimeout or a timeout-class failure
Signal: The client receives RequestTimeout or a timeout-class failure after partial/no request body progress.
Why it matters: Retry may help only if transfer design changes or the part is small enough to retry safely.
02:27 UTC
Upload path moves to buffered multipart transfer
Signal: Data is chunked, parts retry independently, and source generation no longer stalls the S3 request body.
Why it matters: That confirms the incident lived in transfer design or network path.
Seen in Production
The on-the-fly CSV export
Frequency: high
Example: A server queries 10 million rows and streams them to S3. The DB gets slow at row 5M, the stream stops for 30s, S3 kills the connection.
Fix: Fetch data in chunks, store in a local buffer, and upload using multipart parts.
Presigned single-part mobile upload times out
Frequency: common
Example: A mobile client uploads a large video over weak network and the single request stalls repeatedly.
Fix: Use presigned multipart upload with resumable part state and bounded part sizes.
Wrong Fix vs Better Fix
Increase retries vs split the transfer
Wrong fix: Raise retry count while keeping a huge single-part upload.
Better fix: Use multipart upload with bounded part size and independent part retries.
Why this is better: A timeout then repeats only one part instead of restarting the full object.
Stream slow source vs buffer first
Wrong fix: Pipe a slow database/export/compression stream directly into S3.
Better fix: Buffer into stable chunks, then upload chunks at predictable throughput.
Why this is better: S3 upload requests should not wait on unpredictable source generation pauses.
Tune SDK only vs inspect proxy path
Wrong fix: Change SDK timeouts without checking load balancer, proxy, firewall, and NAT idle limits.
Better fix: Align timeouts and keepalive behavior across every hop in the upload path.
Why this is better: Intermediate infrastructure can close idle uploads before the SDK or S3 does.
Debugging Tools
- -AWS S3 Transfer Acceleration speed comparison
- -S3 server access logs
- -SDK debug logs with request IDs
- -Proxy/load balancer idle timeout logs
How to Verify the Fix
- -Upload representative large files under simulated throttling and confirm multipart retries complete successfully.
- -Verify transfer logs show bounded part size, part retry counts, and no long source-read stalls.
- -Confirm S3 request timeout rates drop by bucket/key prefix, client network, and file size.
- -Run proxy-path tests and confirm idle timeouts exceed expected part upload duration.
How to Prevent Recurrence
- -Standardize uploads on SDK transfer manager or explicit multipart for large or unreliable transfers.
- -Set multipart thresholds, part size, concurrency, and retry policy based on measured throughput.
- -Instrument producer read gaps, socket write gaps, part duration, retry reason, and network path.
- -Align application, SDK, proxy, and firewall timeout settings with expected part duration.
Pro Tip
- -for global clients, prefer presigned multipart upload plus Transfer Acceleration testing so traffic does not bottleneck through the app server.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.