onboarding agent hit github api rate limit mid repo provisioning

TL;DR

Your agent burned through GitHub's API rate limit halfway through provisioning repos, so the remaining setup steps fail with 403s and new hires get half-built repos. The fix: read the rate limit headers before heavy loops, back off when the remaining budget is low, and make provisioning resumable so it picks up where it stopped instead of starting over.

The error

GitHub API: 403 "API rate limit exceeded for installation ID [id]."
Agent log: repo 7 of 12 created, then 403s

Steps

1. Confirm it is the rate limit. Check the response headers on the failing calls for the remaining count and reset time. Expected output: remaining at or near zero, with a reset timestamp.
2. Stop and wait, do not hammer. Pause provisioning until the reset time. Expected output: the limit resets and calls succeed again.
3. Record progress per repo. Save which repos are done so a restart resumes at repo 8, not repo 1. Expected output: a progress record showing 7 of 12 complete.
4. Add budget checks before heavy loops. Read the rate limit status first and skip or defer work when the budget is low. Expected output: the agent defers gracefully instead of hitting the wall.
5. Resume the provisioning run. Expected output: repos 8 through 12 get created and the run completes.

When to use

• Provisioning fails partway with 403 rate limit errors
• The agent makes many API calls in a tight loop
• The failure correlates with busy hours when other integrations also call the API

When not to use

• The first call fails with 401: your credential or app installation is wrong
• You get 404s: the repo or org name is wrong
• Secondary rate limits (abuse detection): slow down and spread calls out, a different throttle

Tool compatibility

GitHub REST API via personal access tokens, GitHub Apps, and OAuth apps, on github.com and GitHub Enterprise. The budget-check and resumable-progress patterns apply to any rate-limited API.

Variant phrasings

github api rate limit exceeded provisioning

Wait for reset, resume from saved progress.

github 403 mid automation

Check whether it is the primary rate limit or abuse detection.

agent burned github api budget

Add budget checks before heavy loops.

repo provisioning stalled halfway

Make the run resumable, not restartable.

Why it happens

GitHub's rate limit is per installation or per token, shared across everything using that credential. An agent provisioning a dozen repos can easily fire hundreds of calls (create repo, set teams, add collaborators, configure branch protection, seed files), and it shares the budget with CI, other agents, and dashboards. The agent has no sense of the budget, so it spends it all on the first repos and starves the rest. Reading the limit headers turns an invisible budget into a number the agent can plan around.

Edge cases

• Secondary rate limits trigger first: these 403s come with a retry-after. Honor it; waiting out the primary reset will not help.
• Multiple agents share one installation: give heavy provisioning its own GitHub App installation with a separate budget.
• The reset wait is hours long: queue the remaining work and notify the new hire's manager instead of blocking silently.
• Enterprise Server has different limits: check your instance's documented limits, not the github.com numbers.

Provenance

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