agent assumed a 429 meant stop — the API actually wants exp

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.

Not specified by the original author.

Treat HTTP 429 as a pause, not a fatal error. Change the generated client so a 429 triggers exponential backoff with retries instead of aborting the sync job. Most APIs define 429 as slow down and try again, so the job resumes on its own and finishes instead of dying at the first rate limit.

agent assumed a 429 meant stop  -  the API actually wants exponential backoff and resume, so the sync job aborted instead of recovering

Steps

1. Find where the generated client handles HTTP errors and read what it does on status 429 today: exits, raises, or marks the job failed. Confirm the abort path with one log line or stack trace from a real run. Expected: You can point at the exact branch that kills the job on 429.

2. Replace the abort-on-429 branch with a retry loop: wait, retry the same request, and double the wait each attempt (2 seconds, then 4, then 8), up to a sane max number of tries. Keep the request itself unchanged. Expected: A 429 now produces a wait and a retry instead of a job failure.

3. Honor the Retry-After response header when the API sends one: sleep for the number of seconds it names instead of the computed delay. Fall back to the computed delay when the header is absent. Expected: Logs show the client waiting exactly as long as the API asked on 429s that carry the header.

4. Re-run the sync under realistic load and confirm the job pauses on 429s, resumes, and completes with all records instead of stopping at the first rate limit. Expected: Sync logs show 429, then waits, then resumed requests, and the job finishes with the full record count.

Use this when

• generated client exits, raises, or fails the job on HTTP 429
• the API docs describe 429 as transient and ask clients to back off and retry
• sync or import jobs abort under load at the first rate limit

Not for this skill when

• the 429 comes with a body saying the key is suspended or banned - retrying will not help, fix the credential
• the limit is per-endpoint and one global backoff throttles healthy endpoints too
• parallel workers retry in lockstep and need jitter added first

Variant phrasings

429 too many requests abort

sync job stops on rate limit

handle 429 with retry after

exponential backoff and resume on 429

Why it happens

Agents tend to map every 4xx status to permanent failure, because most 4xx errors really are the client's fault and retrying them is pointless. But 429 is the deliberate exception: the HTTP spec defines it as the server asking the client to slow down and try again. Aborting on 429 throws away partial progress and turns a brief pause into a failed job, which is exactly backwards from what the API wants.

Edge cases

• Some APIs send 429 for a suspended key - read the response body before assuming backoff will fix it
• Cap the total wait time so a heavily throttled job does not exceed its scheduler timeout
• Parallel workers each backing off independently can still pile up - add jitter if they retry in sync
• Log each backoff at warning level so operators can see throttling in the job output

Provenance

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

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

Thread query: agent assumed a 429 meant stop - the API actually wants exponential backoff and resume, so the sync job aborted instead of recovering

TL;DR:

Not specified by the original author.

TL;DR

Stop the retry storm, honour the retry guidance from the 429 response, batch pending status changes into one write, and resume posting at a paced rate with jitter. Work from the run trace, not from guesswork: find the first failing step, apply the targeted fix in the steps below, prove it on a test incident, and only then rerun the workflow against the live incident. If the incident is still ongoing, post the update manually first so customers are not kept waiting while the automation is repaired.

Statuspage API rate limit hit mid-incident-update-posting: agent failed with error 429 too many requests

Use this when

• An agent or automation run fails with this pattern while posting, resolving, syncing, or publishing status page content.
• The run trace shows this error and the public page does not match the intended incident state.
• The same workflow succeeded before and started failing during a live incident or a long run.
• You need the workflow reliable again before the next incident, not just this run rescued.

Not for this skill when

• A human responder sees this error in the admin console with no automation involved. Use the error-specific status page skill instead.
• The underlying product outage is still unresolved. This skill repairs the communication workflow, not the outage.
• You are evaluating agent frameworks in general. This skill only fixes the named failure pattern.

Steps

1. Open the failed run trace and find the first step that diverged: record the step name, the tool or API it called, the exact error, and what state the status page was in at that moment. Do not rerun the whole workflow yet, because a blind rerun during a live incident can duplicate updates or notifications. Verify: you can name the single failing step and the exact error it returned
2. Pause all non-essential polling loops that share the same API key and keep only the incident writer active. Keep the change scoped to the failing step and note the previous behaviour so you can revert quickly. Verify: the isolated fix is in place and a dry test of that step alone no longer returns the original error
3. Read the retry guidance in the 429 response headers and wait at least that long, adding jitter so multiple workers do not retry together. Use a test incident, a staging page, or a draft update for this test wherever the product allows it, so subscribers are not notified by a diagnostic run. Verify: the step completes against the test target and produces the expected state change
4. Coalesce queued status changes into a single batched update and post it once the wait expires. This guard is what turns a one-off fix into a reliable workflow, so add it to the workflow definition itself, not just to this run. Verify: the guard triggers correctly when you simulate the original failure condition
5. Rerun the workflow end to end on a test incident and watch the public page as a logged-out visitor while it runs. Check the incident state, the component statuses, and the subscriber notification behaviour against what the workflow intended. Verify: the public page matches the intended end state exactly and no duplicate update or notification was produced
6. Post the real incident update manually if the incident is still live, rather than waiting for the repaired workflow, and record the failure pattern and fix in the team runbook. Note which credential, file, or limit was involved so the next on-call recognises the pattern immediately. Verify: the live incident has its update posted and the runbook entry is saved where responders will find it

Why it happens

Agents poll and post far faster than human responders. During an incident, several loops sharing one API key exhaust the per-key budget, and immediate retries without backoff keep the key saturated so even the critical update cannot get through. These failures cluster during major incidents for structural reasons: APIs slow down and rate limits tighten under load, credentials expire during long runs, input files assembled in a hurry contain bad rows, and agents fill retrieval gaps with plausible but invented values. A workflow designed for the happy path has no read-back check, no attempt limit, and no input validation, so the first real-world irregularity aborts the run or publishes something wrong. The fixes above add exactly those three guards at the step where this failure occurred.

Variants and edge cases

Same failure pattern against a different status or incident API

The identical pattern (timeout, limit, parse, or auth) against PagerDuty, Incident.io, FireHydrant, Better Stack, or Opsgenie instead of Statuspage. The guard is the same; only the read-back endpoint and the credential store change, so port the fix rather than redesigning the workflow.

Failure only during major incidents, never in tests

Load-dependent variants pass every test and fail live. Reproduce with realistic conditions: a long run, a large timeline, and the production rate limit, and tune timeouts, pacing, and context size from that test rather than from the quiet staging environment.

Agent reports success but the page never changed

The most dangerous variant, where no error surfaces at all. It is prevented by the final read-back step in this skill: the workflow must compare intended state with actual public state and fail loudly on any mismatch, every run, not only after a known error.

Compatibility: Applies to agent workflows driving Atlassian Statuspage, Better Stack, Instatus, PagerDuty, Incident.io, FireHydrant, and Opsgenie APIs as of October 2026, using standard HTTP clients and common agent runtimes. Confirm endpoint and limit details against the provider changelog for your plan.

Provenance

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

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

Thread query: Statuspage API rate limit hit mid-incident-update-posting: agent failed with error 429 too many requests

TL;DR: Stop the retry storm, honour the retry guidance from the 429 response, batch pending status changes into one write, and resume posting at a paced rate with jitter. Work from the run trace, not from guesswork: find the first failing step, apply the targeted fix in the steps below, prove it on a test incident, and only then rerun the workflow against the live incident. If the incident is still ongoing, post the update manually first so customers are not kept waiting while the automation is repaired.