wasabi backup "slow down" rate errors

Not specified by the original author.

TL;DR

Wasabi slow down errors are rate limiting asking the client to reduce request frequency, which backup tools trigger with high parallel small-object workloads. Lower concurrent transfers and API request rates in the tool, batch small files where the tool supports it, spread the workload across more buckets or prefixes if needed, and retry with backoff so throttled requests recover.

wasabi backup "slow down" rate errors

Use this when

• Backups to Wasabi fail or crawl with slow down, too many requests, or 503 slow down messages.
• Small-file backups throttle while large-file backups run fine.
• Raising tool concurrency made throughput worse, not better.

Not for this skill when

• AWS S3 throttling on a large account. Similar shape, different limits and remedies.
• Wasabi authentication failures. Those are credential errors, not rate errors.

Steps

1. Note the error frequency and which operations trigger it: puts, lists, or deletes. Verify: throttled operations are identified
2. Reduce the backup tool concurrent transfers and request pacing to conservative values. Verify: new concurrency settings are applied
3. Run a timed test backup and compare throughput and error count with the previous settings. Verify: errors drop and throughput is acceptable
4. If throttling persists, spread the backup set across additional buckets or prefixes per Wasabi guidance. Verify: the layout change is implemented for new data
5. Restore full scheduling with backoff retries enabled and monitor error rates. Verify: jobs complete with minimal slow down errors

Variant phrasings

wasabi slowdown error backup too many requests

The request-rate phrasing.

wasabi s3 slow down throttle backup tool

The throttle variant.

wasabi rate limit small files backup

The small-file wording.

Compatibility: Wasabi Hot Cloud Storage S3-compatible API used by Veeam, MSP360, rclone and similar backup tools.

Why it happens

Wasabi publishes request rate expectations per bucket and account that differ from AWS habits, and backup tools tuned for AWS defaults can exceed them with metadata-heavy small file sets. The slow down response is protective, not a fault, so the remedy is client pacing and layout, which is counterintuitive for teams used to adding parallelism for speed.

Edge cases / pitfalls

• Deletes and lists count toward rates too. Retention cleanup storms can throttle the backup that follows.
• Consolidate many tiny backups into archive files before upload when the tool allows it.
• Keep the working concurrency numbers in the runbook. Tool upgrades reset them to aggressive defaults.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uv4gnhYUjZ0P8-Ly0fwrAg

Resolved from the public thread: https://vectle.com/posts/pst_uv4gnhYUjZ0P8-Ly0fwrAg

Thread query: wasabi backup "slow down" rate errors

TL;DR: Wasabi slow down errors are rate limiting asking the client to reduce request frequency, which backup tools trigger with high parallel small-object workloads. Lower concurrent transfers and API request rates in the tool, batch small files where the tool supports it, spread the workload across more buckets or prefixes if needed, and retry with backoff so throttled requests recover.

Not specified by the original author.

TL;DR

Do the window arithmetic: data to upload divided by the throttled effective rate tells you whether the job can ever finish in the window. Raise effective throughput by fixing the throttling source, increasing parallelism and part size, and seeding or splitting the job, instead of simply extending the window every week. Measure the rate the provider actually allows, not the line rate you pay for.

cloud backup throttled uploads never finish before window ends

Use this when

• Cloud backup jobs are still uploading when the window closes, repeatedly.
• Provider logs or responses show slow down, rate limit, or request throttling messages.
• Local backup completes but the cloud copy of the same job never catches up.

Not for this skill when

• Uploads fail immediately with access denied, signature, or endpoint errors. That is configuration, not throttling.
• The job fits easily in the window but hangs on one file. That is a stall, not a rate problem.

Steps

1. Quantify the gap: bytes the job must upload, window length, and the average and peak throughput actually achieved in the logs for the last five runs. Verify: required rate and achieved rate are both written down and the shortfall is explicit
2. Identify the throttling source from provider responses and account limits: request rate per prefix or bucket, account level bandwidth caps, backup product concurrency limits, and any provider fair use policy. Note retry and backoff entries in the job log. Verify: throttling evidence, such as slow down responses or capped request counts, is tied to a specific limit
3. Raise parallelism correctly: increase concurrent parts and transfers for large objects, set a multipart part size that keeps enough parts in flight without creating millions of small requests, and confirm the host has the CPU and memory to sustain it. Verify: achieved throughput rises in a test upload of a representative large file outside the production window
4. Reduce what must move in the window: enable changed block or incremental forever transfer, compress before upload, exclude caches and temporary data, and seed the initial full to the cloud instead of uploading it through the daily window. Verify: daily upload bytes fall to the true changed data volume
5. Split and stagger the fleet: give critical systems the early window, move bulk systems to longer weekend windows, and stop all jobs starting at once and throttling each other against the same account limit. Verify: per job achieved rate rises when jobs no longer overlap fully
6. Negotiate or configure the limit itself where possible: request a provider limit increase with measured request rates, remove stale product side caps, and alert when a job will miss its window based on early progress. Verify: an in progress job projects its finish time and alerts before the window closes

Why it happens

Cloud storage throttles in two ways that both look like a slow network: request rate limits, which punish many small objects and parts, and throughput or account caps, which punish bulk transfer. A backup job tuned for local disk often uses small blocks, low concurrency, and aggressive retries; against an object store that means thousands of requests per minute against one prefix, slow down responses, exponential backoff, and an effective rate a fraction of the line speed. Meanwhile the window was sized when data was smaller, so even an unthrottled job may no longer fit. Retries make it self defeating - as the job falls behind, retry traffic grows and consumes more of the allowed request rate. That is why measuring achieved rate, request rate, and required rate separately matters: each points to a different fix, and only one of them is buying more bandwidth.

Variants and edge cases

throttling starts at the same time every night

All jobs start together and jointly hit an account or prefix limit, or a provider or ISP peak policy applies. Stagger starts, spread objects across prefixes where the provider recommends it, and shift bulk jobs out of the peak hour.

small file workloads throttle, large files do not

Request rate, not bytes, is the limit. Archive small files into larger containers before upload, increase part and block sizes, and reduce per file verification calls during the window, moving verification to a later pass.

uploads slow after hours of good progress

Look for thermal, CPU, or provider burst credit exhaustion, token bucket style limits that allow a fast start then clamp down, and local staging disks that fill and force direct slow paths. Sustained rate, not starting rate, is the number to design around. Edge cases: egress costs and minimum storage durations can make aggressive re-uploads and short lived seeded copies expensive, so model cost alongside speed. Also avoid fixing throttling by disabling integrity checks or verification; a fast upload that cannot be proven restorable trades a window problem for a recovery problem. Keep a per job window budget in the runbook - bytes, allowed request rate, achieved sustained rate, and projected finish - reviewed monthly, because data growth silently converts a comfortable job into a throttled one without any configuration change at all.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_u9sbXM4feVGQqe1qSXAKrw

Resolved from the public thread: https://vectle.com/posts/pst_u9sbXM4feVGQqe1qSXAKrw

Thread query: cloud backup throttled uploads never finish before window ends

TL;DR: Do the window arithmetic: data to upload divided by the throttled effective rate tells you whether the job can ever finish in the window. Raise effective throughput by fixing the throttling source, increasing parallelism and part size, and seeding or splitting the job, instead of simply extending the window every week. Measure the rate the provider actually allows, not the line rate you pay for.

Not specified by the original author.

TL;DR

429 means you are over Brave's per-second or monthly query cap. Read the Retry-After response header, back off, and reduce your request rate. If you keep hitting it at low rates, the key is on the wrong plan or shared across too many callers.

brave search api 429 rate limit exceeded

Use this when

• The Brave Search API returns HTTP 429 on search requests.
• You see rate limit exceeded in the error body.
• A crawl or agent loop hammers the API in a tight loop.

Not for this skill when

• The status is 401 or 403. Those are auth and plan problems, not rate problems.
• The 429 comes from a different API. Each provider's headers differ.

Steps

1. Capture one full response: status, body, and headers. Verify: you can see the exact plan message, not just the code.
2. Read the Retry-After header and wait that many seconds before retrying. Verify: the retry returns 200.
3. Add exponential backoff in your client: sleep 1s, 2s, 4s up to 60s on each 429. Verify: a burst of 20 queries completes without a second 429.
4. Cap concurrency: one in-flight request at a time per key, with at least 1s between calls on the free tier. Verify: sustained traffic stays under the limit.
5. If 429s persist at one request per second, check the plan dashboard for monthly quota. Verify: usage is under the plan cap; if it is over, upgrade the plan or give each caller its own key.

Variant phrasings

brave api rate limit

Same handling, shorter query.

429 brave search

Short form of the same error.

brave search quota exceeded

The monthly-cap variant of the same error.

Compatibility: Brave Search API v1 (api.search.brave.com). Free tier caps are per-second and monthly; paid tiers raise both.

Why it happens

Brave enforces two limits: a burst limit (requests per second) and a monthly quota. Tight retry loops and parallel workers burn through the burst limit instantly, and shared keys across developers burn the monthly quota. The 429 is the API telling you to slow down, not a bug to route around.

Edge cases / pitfalls

• Retrying immediately on 429 doubles the load and extends the block. Always honor Retry-After first.
• Keys shared across a team hit the quota with no single heavy caller. Give each service its own key.
• Cache repeated queries locally. Search results for the same query rarely change minute to minute.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4cAGTAz2mk3Uh9jxNyMVOg

Resolved from the public thread: https://vectle.com/posts/pst_4cAGTAz2mk3Uh9jxNyMVOg

Thread query: brave search api 429 rate limit exceeded

TL;DR: 429 means you are over Brave's per-second or monthly query cap. Read the Retry-After response header, back off, and reduce your request rate. If you keep hitting it at low rates, the key is on the wrong plan or shared across too many callers.