GitHub organization outside collaborator review failed: API rate limit error fix

TL;DR

Slow the review down and make it resumable instead of retrying harder, because retries against a rate limit deepen the limit. Read the rate limit response headers to learn the reset time and remaining budget, switch the job to page through collaborators with conditional requests and a checkpoint file, and authenticate with the organization installation or app identity that carries the right quota. A review that checkpoints after every page can pause at the limit and finish after reset without losing work or double counting collaborators.

GitHub organization outside collaborator review failed: API rate limit error fix

Use this when

• An outside collaborator audit fails partway with a rate limit or abuse detection response.
• The organization has hundreds of repositories and collaborators to enumerate.
• The job restarts from zero after every failure.

Not for this skill when

• Calls fail with a not found or forbidden response on one repository. That is a permission problem on that repository.
• You only need the collaborator list for one repository. A single targeted call avoids this machinery.

Steps

1. Capture the failing response status and its rate limit headers, including remaining calls and reset time, from the job log or a repeated single call. Verify: the reset time and remaining budget are recorded.
2. Identify the identity the job uses, personal token, GitHub App installation or Actions identity, and check its rate limit bucket with a status call. Verify: the identity and its hourly budget are known.
3. Add pagination with the maximum page size the endpoint allows and a checkpoint that saves the last completed repository or page after each successful response. Verify: the job writes a checkpoint that a restart can read.
4. Insert pacing based on the remaining header value, slowing as the budget falls and pausing until reset when it reaches the floor rather than erroring out. Verify: the job pauses and resumes on its own across a reset in a test run.
5. Use conditional requests or the organization level collaborator listing where available instead of querying every repository separately, and compare the resulting totals. Verify: the collaborator count matches a spot check in the organization settings.
6. Run the full review to completion across a reset boundary, then reconcile the final list against the organization outside collaborator view for a sample of repositories. Verify: the completed list matches sampled repositories with no gaps.
7. Save the checkpoint design and pacing settings in the runbook so the next quarterly review starts resumable by default. Verify: the runbook names the checkpoint location and the pacing rule.
8. Add a dry run mode to the review job that counts the API calls a full run will need from the organization size before it starts, and warns when the count exceeds the identity hourly budget. Verify: a dry run prints the expected call count and the budget warning threshold.

Why it happens

GitHub rate limits are per identity and per hour, and collaborator enumeration multiplies calls by repositories and pages. A naive job spends its whole budget quickly, fails, and then spends the next budget re-fetching the same first pages. Checkpoints and header driven pacing turn the limit from a failure into a scheduled pause. Choosing an identity with the right quota and preferring organization level listings cut the total calls, which matters more than any retry trick.

Variants and edge cases

GitHub API secondary rate limit on collaborator audit

The secondary limit phrasing. Secondary limits punish bursts, so spacing requests matters as much as the hourly total.

outside collaborators list incomplete for large org

The completeness phrasing. An incomplete list usually means the job died mid-pagination; check for a checkpoint before trusting it.

403 rate limit exceeded in GitHub review script

The status phrasing. A 403 with rate limit headers is a limit, while a plain 403 is permissions; read the headers to tell them apart.

Edge cases to check before closing the review cycle:

• GitHub Enterprise Server has its own limits and headers. Confirm which host the job targets before applying cloud numbers.
• Fine grained tokens can have lower effective access per repository. The app installation route is usually cleaner for org wide reviews.
• Never share one personal identity across several review jobs; they will consume one budget and fail together.

Compatibility: GitHub REST API organization and collaborator endpoints, GitHub Apps and fine grained tokens, GitHub Enterprise Cloud and Server.

Provenance

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