TL;DR: Page 40 of the GitHub search API does not exist; search caps at 1000 results and 10 pages of 100. Split the triage query into date windows that each stay under 1000 results, use per_page=100, respect rate-limit headers, and checkpoint after every page so a crash resumes instead of restarting.

```text
agent timed out fetching 900 workerd github issues for triage, search failed at page 40
```

## Steps

1. Switch the search calls to per_page=100, the maximum page size.
   Expected: 10 pages cover up to 1000 results per query, with far fewer requests.
2. Split the triage query into date windows (e.g. created:2026-01-01..2026-03-31) so each window returns under 1000 results.
   Expected: every window is fully pageable; no window silently truncates.
3. Read the rate-limit headers on each response and sleep when the remaining budget runs low, instead of bursting until a 403.
   Expected: no rate-limit aborts mid-run.
4. Checkpoint after each page: write the completed page number to a file and resume from the checkpoint on failure.
   Expected: a crash at page 40 resumes at page 40, not page 1.
5. If the goal is "every issue" rather than keyword matches, use the issues list endpoint instead of search.
   Expected: complete enumeration without the 1000-result search cap.

## Use this when

- A triage agent bulk-fetches GitHub issues and fails partway through
- Search pagination stops or errors around page 10
- Rate limits kill long triage runs

## Not for this skill when

- You need fewer than 1000 results total (plain pagination works fine)
- The failure is authentication rather than pagination or rate limits
- The repo has fewer issues than one page (just fetch them)

## Variant phrasings

- github search api only returns 1000 results
- github api pagination stops at page 10
- triage agent rate limited fetching issues
- fetch all issues in a repo over 1000

## Why it happens

The GitHub search API hard-caps results at the first 1000 matches and 10 pages of 100 per query; requesting page 11+ returns an error, and page 40 was never reachable. Long triage runs also burn through the search rate limit (30 requests per minute for authenticated users), so bursting without backoff guarantees a 403 partway through. Agents that assume "keep incrementing the page" hit both walls.

## Edge cases

- The 1000-result cap applies per query; overlapping date windows can double-count issues, so dedupe by issue id.
- Search results are eventually consistent; a brand-new issue may not appear for a minute.
- The issues list endpoint paginates past 1000 but is slower and has its own rate limits; checkpoint there too.
- For huge repos, narrow by label or milestone in addition to date to keep windows small.

## Provenance

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