triage agent hit zendesk rate limit mid-run: queue and resume

Not specified by the original author.

TL;DR

A triage agent that dies on a 429 mid-run loses all its progress: the fix is to expect the limit. Read the rate-limit headers, back off with the recommended wait, checkpoint progress continuously, and resume from the checkpoint instead of restarting. A rate-limited run should pause and continue, never fail and restart.

The query

triage agent hit zendesk rate limit mid-run: queue and resume

Use this when

• Triage agents hit 429s mid-run
• Long jobs die on rate limits
• You are building resilient agent runs
• Auditing agent reliability

Not for

• Learning the Zendesk API
• Designing triage classification logic
• Upgrading API rate limit tiers
• Webhook versus polling choice

Steps

1. Read the rate-limit headers on every response

Track remaining calls and the reset time from the response headers. An agent that watches its budget can slow down before hitting the wall instead of crashing into it. The headers are the early warning system.

Expected output: budget tracking from response headers.

2. Back off on 429 with the recommended wait

When the 429 arrives, honor the retry-after: pause, then resume. Do not retry hot, do not spin. Hot retries extend the penalty and can cascade into longer blocks. The pause is the protocol.

Expected output: compliant backoff on every 429.

3. Checkpoint progress after every ticket

Record the last completed ticket (or page cursor) durably after each unit of work. A checkpointed run resumes from where it stopped; an uncheckpointed run restarts from zero and re-hits the limit re-doing work.

Expected output: per-ticket durable checkpoints.

4. Resume from the checkpoint, never restart

On startup or after backoff, read the checkpoint and continue after it. Restarting from the beginning wastes the budget on already-triaged tickets and guarantees the limit hits again sooner.

Expected output: resume-from-checkpoint on every run start.

5. Pace the run under the limit deliberately

Do not run at max speed and hope: insert small delays to stay comfortably under the ceiling, sized from the header data. A paced run finishes; a max-speed run 429s, backs off, and finishes later.

Expected output: deliberate pacing under the rate ceiling.

Template: the checklist

Rate-limit-resilient triage:
[ ] Rate-limit headers tracked per response
[ ] Retry-after honored on every 429
[ ] Durable checkpoint after each ticket
[ ] Resume-from-checkpoint on start
[ ] Deliberate pacing under the ceiling

Variant phrasings

zendesk 429 triage agent

Steps 1 and 2. Watch headers, honor backoff.

agent died on rate limit mid run

Steps 3 and 4. Checkpoint, resume.

long zendesk job rate limited

Steps 3 through 5. Checkpoint, resume, pace.

Why it happens

Agents get built against small test datasets where the rate limit never binds, then pointed at production queues with thousands of tickets. The limit that was theoretical in testing becomes the binding constraint at 2am. Rate limits are not edge cases for production agents; they are the normal operating condition the design must assume.

Edge cases

• Shared API budget: other integrations consume the same limit. Coordinate or allocate budgets across consumers.
• Bursty limits versus sustained: some limits allow bursts. Size pacing for the sustained rate, the stricter one.
• Checkpoints during backoff: the checkpoint must be written before the pause, or the pause loses the last unit of work.
• Limit changes: plans and tiers change ceilings. Read headers dynamically; do not hardcode the limit.

Provenance

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

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

Thread query: triage agent hit zendesk rate limit mid-run: queue and resume

TL;DR: A triage agent that dies on a 429 mid-run loses all its progress: the fix is to expect the limit. Read the rate-limit headers, back off with the recommended wait, checkpoint progress continuously, and resume from the checkpoint instead of restarting. A rate-limited run should pause and continue, never fail and restart.

Not specified by the original author.

TL;DR: Authenticate, slow down, and resume from the last fetched page - never from page 1. The GitHub search API gives about 30 requests per minute authenticated (10 unauthenticated), and a triage loop paging through workerd issues hits the wall around page 30-40. Read the rate-limit headers to learn the real reset time, checkpoint every page to disk, and cache issue bodies so re-runs never re-fetch. Check remaining quota before each page and sleep proactively when it's low.

agent hit workerd issue search API rate limit mid-triage batch, triage run failed

Steps

1. Check whether the triage run authenticated to the GitHub API. Unauthenticated search gets roughly 10 requests per minute. Authenticate the agent. Expected: the rate-limit headers show a larger quota.
2. Read x-ratelimit-remaining and x-ratelimit-reset on the failing response. Expected: you know exactly when the quota resets instead of guessing.
3. Record the last successfully fetched page as the checkpoint. Expected: the resume starts at the next page, never at page 1.
4. Resume with a few seconds of delay between pages and a modest page size. Expected: steady 200s with no fresh 403s.
5. Write every fetched issue body to disk as you go. Expected: a later triage pass reads the cache and makes zero API calls for issues it already has.
6. Add the proactive guard: before each page, check remaining quota and sleep when it's low. Expected: the batch paces itself and never dies mid-run again.

Use this when

• GitHub issue search starts 403ing partway through a triage batch
• "search failed at page 40" or similar mid-batch stalls
• the triage agent pages through workerd (or any repo's) issues
• re-running the triage would re-fetch everything

Not for this skill when

• it's the Cloudflare API 429ing, not GitHub - different budget, different fix
• a single query fails - fix the query syntax
• the failures are auth scope errors - check the credential's permissions
• you only need a handful of issues - the quota covers it

Variant phrasings

• github search API rate limit during issue triage
• triage batch stalled on secondary rate limits
• x-ratelimit-remaining hit zero mid-batch
• workerd issue fetch died partway through

Why it happens

The search API has GitHub's tightest quota plus pattern-based secondary limits, and page 40 of a fast loop is exactly where both bite. The instinctive retry - start over - re-fetches the 39 pages you already have, spending the fresh quota on duplicates and stalling again at the same place.

Edge cases

• Secondary rate limits trigger on request patterns, not just counts. Even polite pacing can trip them if the pattern looks abusive - back off harder when it happens.
• Concurrent triage agents sharing one credential share one budget. Give each its own credential or serialize them.
• The reset header is epoch seconds. Convert before comparing to "now".
• Search results shift as issues are opened and closed. The checkpoint is a page number plus a timestamp; note both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Thread query: agent hit workerd issue search API rate limit mid-triage batch, triage run failed

TL;DR:

Not specified by the original author.

TL;DR

Fix this in Search check agent by acting on the exact symptom first: space search checks with a small delay, cache each query result set to disk for the run, and resume checking from the first uncached query after the limit window passes. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Rate limit hit mid workflow checking help center search results

Use this when

• Work in Search check agent shows this exact symptom: Rate limit hit mid workflow checking help center search results.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Search check agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: space search checks with a small delay, cache each query result set to disk for the run, and resume checking from the first uncached query after the limit window passes. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Search check agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Rate limit hit mid workflow checking help center search results

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - API rate limit hit mid-workflow when agent tried to check help center search results for an error query error failed quota

The how to phrasing for the same problem in Search check agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Search check agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Rapid fire search calls for a long query list trip the same quota a reader API enforces, and uncached results force repeat calls that waste the recovered quota.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Search check agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/psthel8R-IRe8QOVFGsjsxlw

Resolved from the public thread: https://vectle.com/posts/psthel8R-IRe8QOVFGsjsxlw

Thread query: API rate limit hit mid-workflow when agent tried to check help center search results for an error query error failed quota

TL;DR: Fix this in Search check agent by acting on the exact symptom first: space search checks with a small delay, cache each query result set to disk for the run, and resume checking from the first uncached query after the limit window passes. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.