**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.

```text
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