## TL;DR
Request timeouts uploading to S3 usually mean parts are too large for a slow or lossy path, too many parallel parts saturate the uplink, or the client waits on a hung connection. Lower multipart size and concurrency to match the uplink, confirm host time sync for signed requests, and use tooling that resumes parts instead of restarting whole objects.

```text
backup upload to S3 failed request timeout
```

## Use this when
- Backup uploads to S3 fail with request timeout or socket timeout.
- Failures cluster on large files or busy uplink hours.
- Local repository backups on the same job succeed.

## Not for this skill when
- S3 returns access denied or no such bucket. Configuration, not timeouts.
- A multipart upload completes parts but the final completion call fails. Different stage.

## Steps
1. Check the backup host uplink utilisation and error rates during a failing upload. Verify: path quality during failure is measured
2. Reduce multipart part size and parallel upload threads in the backup tool S3 settings. Verify: new settings are applied to the job
3. Confirm the host clock is synchronised, since skewed clocks also break signed S3 requests. Verify: time offset is near zero
4. Run a test upload of a large file with the same tool and settings and watch it complete with retries visible but succeeding. Verify: the test object lands and verifies
5. Run the full backup and confirm objects upload without request timeout failures. Verify: the job completes to S3

## Variant phrasings
### s3 upload timeout backup multipart settings
The settings phrasing.
### aws s3 request timeout backup job failed
The job variant.
### s3 socket timeout large file backup
The large-file wording.

Compatibility: AWS S3 and S3-compatible endpoints used by Veeam, restic, rclone, duplicacy and similar tools, with multipart uploads over WAN links.

## Why it happens
S3 itself rarely times out healthy requests; the path and the client settings do. Signed requests expire, home and branch uplinks drop packets under saturation, and very large parts mean each retry re-sends hundreds of megabytes. Right-sizing parts to the link turns timeouts from fatal to merely retried.

## Edge cases / pitfalls
- Endpoint choice matters: an S3 endpoint in the wrong region adds latency that compounds timeouts. Verify bucket region.
- Antivirus or TLS inspection proxies on the path can reset long uploads. Test from a clean path if timeouts persist.
- Tools differ in default part sizes by an order of magnitude. Record the values that work for your link.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0pjJZw-D-fYg0BSLMC8PTw