RequestExpired
AWS RequestExpired (Request Expired) means AWS received a signed request outside the allowed SigV4 time window, after a presigned URL already expired, or with a request timestamp too far in the future. In AWS APIs, this error returns HTTP 400.
Last reviewed: April 21, 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 Expired Mean?
The signed request is too old, too far in the future, or already past its explicit expiration when AWS evaluates it. The useful tuple is x-amz-date, actual send time, presigned URL expiry, and where the request waited after it was signed. If the security token itself expired, treat that as a neighboring ExpiredToken path rather than this code.
Common Causes
- -Host or container clock drift pushes
x-amz-dateoutside the accepted skew window. - -Requests are signed too early and then sit in queues, retries, or worker buffers before transmission.
- -Presigned URLs are cached, shared, or resumed after the expiry timestamp has already passed.
- -Time zone or UTC conversion bugs produce timestamps in local time instead of UTC.
- -Proxy or retry middleware replays stale signed requests without regenerating the signature.
How to Fix Request Expired
- 1Verify UTC clock accuracy on the failing caller before rotating credentials or changing IAM policies.
- 2Check whether the request itself is outside the accepted SigV4 window before rotating credentials; if the token expired, switch to the neighboring
ExpiredTokenbranch. - 3Regenerate the SigV4 signature immediately before dispatch instead of signing earlier in the workflow.
- 4Reduce queue and retry delay between signing and send for batch workers or proxy tiers.
- 5For presigned URLs, mint a fresh URL and add client-side checks that refuse near-expiry links.
Step-by-Step Diagnosis for Request Expired
- 1Capture request ID,
x-amz-date, actual send time, presigned URL expiry when relevant, and AWS error timestamp from the failing path. - 2Compare caller clock against a trusted NTP source across every node that can sign requests.
- 3Check whether the same runtime is also surfacing
ExpiredTokenor another neighboring auth error before treating token lifetime as the root cause of RequestExpired. - 4Measure signature age between signing and outbound transmission for workers, queues, and proxies.
- 5Audit presigned URL TTL, cache lifetime, and client reuse behavior against real user flows.
- 6Check whether retries or middleware are replaying an already-signed request object.
Seen in Production
- -Autoscaled worker starts processing before time sync completes, signs requests with a clock several minutes behind, and immediately triggers
RequestExpiredspikes. - -A queue signs S3 uploads when jobs are created, but workers do not transmit them until several minutes later, so the signature ages out before send.
- -Mobile client resumes from background and reuses a cached presigned upload URL long after the expiry timestamp passed.
- -A proxy retries a previously signed request body after a transient connection fault and replays the original
x-amz-date, so the second attempt arrives outside the allowed window.
Clock and Signature Age Audit
- -Inspect host clock skew against trusted NTP across caller nodes (example: one node drifts beyond the acceptance window while the rest of the fleet stays healthy).
- -Verify signing timestamp generation uses UTC consistently (example: local-time conversion bug places
x-amz-datein the future on one deployment path).
Dispatch Delay and URL Expiry Checks
- -Trace time between signing and transmission for queued or retried workloads (example: jobs sit in queue long enough to expire before the first outbound attempt).
- -Audit presigned URL TTL against real client behavior (example: app stores a 15-minute URL and retries upload after the user resumes hours later).
Decision Shortcut: Clock Drift vs Delayed Dispatch
- -If every request from one node fails immediately and
x-amz-dateis already skewed, prioritize clock sync before touching queue design. - -If requests succeed when sent interactively but fail after queueing or client pause-resume behavior, prioritize signature age and dispatch delay over host time drift.
- -If request age looks normal but auth errors start naming expired tokens explicitly, switch to the neighboring token-expiry branch instead of forcing this incident into RequestExpired.
Wrong Fix to Avoid
- -Do not rotate credentials first if the real problem is signature age; new keys will still fail with the same stale timestamps.
- -Do not only increase presigned URL TTLs when queue or retry design is the real source of delay and drift.
- -Do not assume RequestExpired always means clock skew; queue delay, presigned URL age, and stale signed retries are just as common.
Implementation Examples
2026-04-13T08:41:19Z service=invoice-worker requestId=req_7ab1e9 region=eu-west-1
x-amz-date=20260413T082349Z sentAt=2026-04-13T08:41:19Z signatureAgeSeconds=450
error=RequestExpired message="Request has expired"date -u
timedatectl status | rg 'System clock synchronized|NTP service'
aws s3 ls --debug 2>&1 | rg 'X-Amz-Date|RequestExpired'jq -r '.createdAt, .signedAt, .sentAt' failed-job.json
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=PutObject \
--max-results 5Incident Timeline
08:23 UTC
The request is signed before the worker is actually ready to send it
Signal: A queue-backed job stores x-amz-date and SigV4 material minutes before the outbound request leaves the process.
Why it matters: The first question is not “are the credentials wrong?” but “how old was the signed request when AWS finally received it?”.
08:31 UTC
The failing runtime reveals either drift or stale request age
Signal: Logs show x-amz-date outside the expected window, or signature age is already beyond the acceptable budget by the first outbound send.
Why it matters: This is where RequestExpired splits into two practical branches: bad caller time vs delayed dispatch. The fix path depends on which timestamp drifted first.
08:34 UTC
A retry replays the same stale signature
Signal: Middleware or a gateway resends the already-signed payload after a transient network fault, but keeps the old x-amz-date.
Why it matters: If retries reuse the original signature, they amplify the failure instead of recovering from it.
08:41 UTC
Signing moves to the final hop and the request starts succeeding
Signal: The worker re-signs immediately before send or the client receives a freshly minted presigned URL, and RequestExpired stops without IAM changes.
Why it matters: That confirms the incident was about request age, not permissions.
Seen in Production
Autoscaled nodes boot with unsynchronized clocks
Frequency: common
Example: New instances issue signed requests before NTP sync completes and trigger RequestExpired spikes during scale-out.
Fix: Gate application startup on time-sync health checks and suppress traffic until clocks are healthy.
Queued jobs sign too early and send too late
Frequency: common
Example: Batch pipeline signs requests when the job is enqueued, but workers transmit them minutes later after queue backlog grows.
Fix: Move signing to the worker immediately before send and attach age-budget telemetry to every request.
One deployment path formats SigV4 timestamps in local time instead of UTC
Frequency: medium
Example: A recently changed signer uses local offset handling on one shard, so only that path sends future-dated requests that AWS rejects with RequestExpired.
Fix: Normalize all signing timestamps to UTC and add signing-contract tests around date formatting.
Pre-signed links are cached by clients past intended lifetime
Frequency: rare
Example: Mobile app resumes from background and reuses an expired upload URL hours later.
Fix: Refresh presigned URLs before critical operations and block reuse of near-expiry links client-side.
Proxy retries replay an already-signed request
Frequency: medium
Example: A gateway buffers and retries a signed request body after a transient connection issue, but the second attempt uses the old x-amz-date and is rejected.
Fix: Re-sign on retry or move signing to the final outbound hop instead of replaying a stale signed payload.
Wrong Fix vs Better Fix
Rotate keys first vs prove signature age
Wrong fix: Rotate access keys or STS sessions immediately because the request “looks auth-related.”
Better fix: Measure x-amz-date, actual send time, queue delay, and presigned URL lifetime before touching credentials.
Why this is better: Fresh credentials still fail if the request is being signed too early or replayed too late. Proving request age first prevents unnecessary auth churn.
Longer presigned TTL vs fixing delayed dispatch
Wrong fix: Only increase presigned URL TTL or retry budget and hope the error disappears.
Better fix: Move signing closer to transmission, refresh stale URLs earlier, and reduce queue or retry delay between signing and send.
Why this is better: A larger TTL can hide the symptom briefly, but it does not fix the architectural delay that is aging signatures out in the first place.
Restart workers blindly vs gate on time and signing health
Wrong fix: Restart the failing workers without checking time sync, signing position, or presigned URL age assumptions.
Better fix: Block traffic until NTP is healthy, then ensure requests are signed at the final hop and stale presigned URLs are not reused.
Why this is better: A restart may temporarily reshuffle timing, but it will not make an unsynchronized clock or an over-aged signed request safe under load.
Debugging Tools
- -NTP synchronization metrics (
timedatectl, Chrony, cloud time-sync dashboards) - -AWS CLI --debug
- -Signer telemetry with request age and
x-amz-datecapture - -Queue delay and presigned URL lifecycle logs
How to Verify the Fix
- -Replay the same request path and confirm RequestExpired no longer appears with fresh timestamps.
- -Confirm time-drift dashboards stay within acceptable bounds across every signer node.
- -Verify request age stays inside the accepted window across at least one retry sequence or queue cycle.
- -Verify presigned uploads or queued jobs succeed across at least one full expiration cycle.
- -Check auth-related failure rates drop without shifting the incident into SignatureDoesNotMatch or neighboring token-expiry errors.
How to Prevent Recurrence
- -Standardize time synchronization policy for every compute environment handling SigV4 signing.
- -Avoid caching signed requests or presigned URLs longer than the real send path allows.
- -Sign requests as late as possible in the request lifecycle to minimize stale timestamps.
- -Alert on clock skew, queue delay, and expired-signature trends before they become incident-level failures.
Pro Tip
- -add a signer-side age budget check that refuses outbound calls when signature age is already too close to the expiry threshold.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.