SlowDown
Amazon S3 SlowDown means S3 is applying back-pressure because request rate or request concentration is temporarily exceeding what one hot path can absorb.
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 Slow Down Mean?
S3 is telling the caller to slow down while the service and request path catch up. This is usually not a permission or payload problem. It is a throughput-shaping problem around hot prefixes, bursty traffic, aggressive retries, or one request pattern concentrating too much load on the same S3 path.
Common Causes
- -Many workers hit the same bucket prefix at once, creating a hot path.
- -Object key naming concentrates traffic around sequential or highly correlated prefixes.
- -A bulk migration, log flush, or fan-out job ramps from zero to peak throughput too quickly.
- -Retry storms and list/head polling amplify an already hot S3 path.
- -One caller cohort repeatedly retries without adaptive backoff while S3 is already asking for slower traffic.
How to Fix Slow Down
- 1Confirm the error is
SlowDownand isolate the hottest prefixes or request patterns first. - 2Reduce concurrency and enable jittered SDK retries before adding more workers.
- 3Spread writes and reads across less concentrated key paths when traffic clusters too tightly.
- 4Ramp bulk workloads gradually instead of opening peak throughput instantly.
- 5Stop synchronized retries from multiple workers hitting the same S3 path at the same time.
Step-by-Step Diagnosis for Slow Down
- 1Capture bucket, prefix, operation type, request rate, and retry attempt count during the failure window.
- 2Identify whether the issue clusters around one prefix, one workload, or one time-based flush event.
- 3Inspect key naming patterns for sequential or correlated prefixes that create concentrated traffic.
- 4Measure whether retries,
ListObjects, orHeadObjectpolling are amplifying the incident. - 5Retest with reduced concurrency and adaptive retry behavior before redesigning the whole storage layout.
Seen in Production
- -A midnight log flush pushes thousands of PUTs into the same date-based prefix and S3 responds with SlowDown until demand is smoothed.
- -A fleet retries the same failed upload batch simultaneously, doubling the pressure on the same hot prefix.
- -A polling loop calls
HeadObjectorListObjectsV2on one hot path so frequently that normal writes on the same prefix start getting throttled. - -A migration script starts at full fan-out instead of ramping, and S3 returns SlowDown for the first concentrated burst.
Prefix Concentration and Traffic Shape
- -Measure request distribution by prefix and operation type (example: one date-based path absorbs most writes while the rest of the bucket stays quiet).
- -Inspect key naming strategy for concentration risk (example: sequential timestamp prefixes funnel traffic into one hot area).
Retry Amplification and Ramp Behavior
- -Check whether SDK or worker retries are synchronized (example: every worker retries at the same one-second cadence and re-hammers the hot prefix).
- -Inspect workload ramp shape (example: migration opens 1,000 parallel workers at once instead of gradual warm-up).
Decision Shortcut: Hot Prefix vs General Availability
- -If errors cluster around one prefix or one workload pattern, stay on the SlowDown path before treating it as generic
ServiceUnavailable. - -If every prefix and operation type fails broadly, inspect wider S3 or network availability before redesigning keys.
- -If reduced concurrency and adaptive retries recover the workload quickly, the issue is likely load concentration rather than a deeper outage.
Wrong Fix to Avoid
- -Do not simply add more workers when S3 is already asking you to reduce pressure.
- -Do not rely on blind immediate retries; they often turn a hot prefix into a longer incident.
- -Do not redesign the whole bucket structure before proving where concentration actually lives.
Implementation Examples
2026-04-21T00:02:14Z bucket=prod-logs prefix=logs/2026-04-21/
operation=PutObject rps=4800 retryAttempt=2 status=503 error=SlowDown
message="Please reduce your request rate."import boto3
from botocore.config import Config
config = Config(retries={'max_attempts': 8, 'mode': 'adaptive'})
s3 = boto3.client('s3', config=config)import { createHash } from "crypto";
function partitionedKey(originalKey) {
const shard = createHash("md5").update(originalKey).digest("hex").slice(0, 2);
return `${shard}/${originalKey}`;
}Incident Timeline
00:00 UTC
A workload opens a concentrated burst against one S3 path
Signal: Workers, migrations, or log flushes begin hammering the same prefix or request family simultaneously.
Why it matters: The first useful question is where the traffic is concentrated, not whether credentials or object metadata changed.
00:02 UTC
S3 begins returning SlowDown on the hot path
Signal: One operation family or prefix starts getting 503 SlowDown while unrelated paths may remain healthy.
Why it matters: This is targeted back-pressure, not necessarily a general bucket outage.
00:03 UTC
Retries and polling widen the pressure
Signal: Workers reissue the same requests, and list/head traffic or retry loops increase total pressure on the already hot path.
Why it matters: Retry shape can become the second incident if it is not bounded and jittered.
00:10 UTC
Demand is spread or slowed and throughput stabilizes
Signal: Concurrency is reduced, retries spread out, or key concentration decreases so the same workload starts succeeding again.
Why it matters: That confirms the root cause was traffic concentration and ramp behavior, not object validity or auth semantics.
Seen in Production
Midnight log flush hammers one date prefix
Frequency: high
Example: Hundreds of workers upload to the same logs/2026-04-21/ path at once and start receiving SlowDown.
Fix: Spread key concentration, stagger upload starts, and cap worker concurrency.
Retry storm doubles pressure after first SlowDown
Frequency: common
Example: Every worker retries the same failed PUTs instantly, making the hot path even hotter.
Fix: Adopt adaptive retries with jitter and enforce total retry budgets.
Metadata polling starves real work
Frequency: medium
Example: Frequent list/head polling on one prefix consumes enough capacity that normal writes begin seeing SlowDown.
Fix: Reduce polling cadence and separate metadata scans from hot write windows.
Wrong Fix vs Better Fix
Add more workers vs reduce hot-path pressure
Wrong fix: Scale the workload wider because requests are failing.
Better fix: Lower concurrency, add jitter, and reduce concentration on the hot prefix before widening throughput.
Why this is better: SlowDown is a back-pressure signal. More parallelism often makes it worse.
Blind retries vs adaptive retry discipline
Wrong fix: Retry every failure immediately with the same cadence from all workers.
Better fix: Use adaptive or bounded exponential backoff with jitter and keep total retry volume under control.
Why this is better: Uncoordinated retries amplify the exact pressure that triggered SlowDown.
Global redesign vs targeted prefix analysis
Wrong fix: Assume the whole bucket layout is broken and start a large refactor with no hotspot evidence.
Better fix: Measure request concentration by prefix and operation first, then decide whether key distribution changes are actually needed.
Why this is better: Most SlowDown incidents are concentrated around a specific path or workload pattern.
Debugging Tools
- -CloudWatch S3 request metrics
- -S3 Storage Lens
- -S3 server access logs queried via Athena
- -Worker retry telemetry and concurrency dashboards
How to Verify the Fix
- -Confirm SlowDown rate drops after concurrency is reduced or retries are spread out.
- -Verify the same workload completes successfully without expanding retry storms.
- -Measure that request distribution across prefixes or operation paths is less concentrated.
- -Confirm latency and 5xx trends stabilize after the ramp or key-layout correction.
How to Prevent Recurrence
- -Design high-throughput S3 workloads with explicit concurrency and retry budgets.
- -Monitor request concentration by prefix and operation type, not only bucket-wide totals.
- -Ramp bulk jobs gradually instead of jumping to full fan-out instantly.
- -Review key naming strategy when one prefix repeatedly becomes a hotspot under production load.
Pro Tip
- -treat list/head polling volume as part of the same budget as writes because metadata traffic can trigger SlowDown too.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.