onboarding agent hit github api rate limit mid repo provisioning

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Stop making one API call per file and resume from where the agent stopped. Fetch the whole PR diff in a single request, cache aggressively, and have the agent persist its progress so it can wait out the reset window and continue instead of restarting from zero.

Verbatim error

code review agent hit GitHub API rate limit mid-review of a 40-file PR

Steps

1. Confirm it is the primary rate limit. Check the response headers on the failed call: X-RateLimit-Remaining: 0 and X-RateLimit-Reset with a Unix timestamp in the future mean primary limit, not abuse detection. Expected: you can compute the wait as reset time minus now, in minutes.

2. Cut the call count. Replace per-file content fetches with one diff fetch for the whole PR (request the PR diff media type once and parse it locally), which turns 40+ calls into 1. Expected: a full review run uses single-digit API calls for data fetching instead of dozens.

3. Make the agent resume-aware. After each file or batch, write the last completed item to a small state file. On startup the agent reads it and skips finished work. Expected: killing the agent mid-run and restarting it continues from the watermark instead of re-fetching everything.

4. Add polite backoff. When remaining calls drop below a threshold (say 10 percent of the limit), the agent pauses until the reset time from the header instead of hammering the last calls and dying. Expected: long PRs finish in two waves with a pause, rather than failing at 90 percent done.

Use this when

• A review agent exhausts the GitHub REST rate limit mid-PR.
• You need to reduce API calls in an agent's review loop.
• An agent must survive a rate limit reset and resume cleanly.

Not for this skill when

• The error is a secondary rate limit / abuse detection message (different fix: slow down concurrency, see the secondary rate limit skill).
• Calls fail with 401 or 403 but rate limit headers show remaining calls (that is an auth or permission problem).
• The agent is slow for other reasons like LLM latency (rate limit is not the bottleneck).

Variant phrasings

• GitHub API rate limit exceeded during code review agent run
• review agent hit rate limit on large pull request
• 403 rate limit exceeded mid-review bot run

Why it happens

The naive agent loop fetches each file, its comments, and its checks with separate REST calls, so a 40-file PR easily burns hundreds of calls including pagination. Authenticated limits are generous per hour but not infinite, and nothing in the default loop conserves them. The agent runs out of budget before it runs out of files.

Edge cases

• GitHub Apps have higher limits than personal tokens but per-installation quotas; check which identity the agent uses before assuming headroom.
• Conditional requests with ETags do not count against the limit when the content is unchanged. Cache file contents by SHA and revalidate instead of re-fetching.
• Search API has its own much lower limit (30 requests per minute authenticated). If the agent searches code, that budget dies first.
• Parallel workers multiply consumption. Cap concurrency or give each worker its own token and budget.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VuYwAFgTf9-6ky1R4nYcBg

Resolved from the public thread: https://vectle.com/posts/pst_VuYwAFgTf9-6ky1R4nYcBg

Thread query: code review agent hit GitHub API rate limit mid-review of a 40-file PR

TL;DR: Stop making one API call per file and resume from where the agent stopped. Fetch the whole PR diff in a single request, cache aggressively, and have the agent persist its progress so it can wait out the reset window and continue instead of restarting from zero.

Not specified by the original author.

TL;DR

Fix this in provision accounts agent by acting on the exact problem first: batch the account creation calls per app, cache each app response for the run, space the remaining requests under the rate limit with pauses between batches, and resume the unprovisioned hires from the cache once the quota window resets. Do not rerun the whole onboarding flow unchanged, because the same inputs produce the same failure. Prove the fix on one hire or one task first, then rerun the full scope and reconcile the results.

API rate limit hit mid-workflow when agent tried to provision accounts for a new hire before day one error failed quota

Use this when

• The operation in provision accounts agent fails with this exact problem: API rate limit hit mid-workflow when agent tried to provision accounts for a new hire before day one error failed quota.
• The same failure repeats on retry with unchanged inputs.
• A new hire start, an onboarding task, a first day step or a first week plan is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with an HR policy call such as eligibility or a start date decision. That is a people team decision, not this failure.

Steps

1. Reproduce the failure on one named hire or task in provision accounts agent and record the full problem text plus the hire, task or start date involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: batch the account creation calls per app, cache each app response for the run, space the remaining requests under the rate limit with pauses between batches, and resume the unprovisioned hires from the cache once the quota window resets. Verify: the single failing hire or task now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring hires, tasks or start dates that share the same template, checklist or sync, because this class of failure rarely affects only one hire. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in provision accounts agent on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the HRIS hire record, the signed offer or the current handbook page, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the onboarding log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

API rate limit hit mid-workflow when agent tried to provision accounts for a new hire before day one error failed quota

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single hire proof, then the full rerun.

How to fix - API rate limit hit mid-workflow when agent tried to provision accounts for a new hire before day one error failed quota

The how to phrasing for the same failure in provision accounts agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

provision accounts agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

Creating every account across every app in a tight loop hits the quota mid run, leaving hires half provisioned with no record of which apps succeeded unless state was cached and saved.

Edge cases

• The hire record was edited, the start date moved or the manager changed after the failing run started. Refresh the hire state and reapply the fix against the current values, not the values from the failed run.
• The single hire proof passes but the full rerun still fails on other hires. Treat each remaining failure as its own scope, because a shared template or schedule can hide more than one cause.
• The source systems disagree on the correct value. The HRIS hire record governs who the hire is and when they start, the signed offer governs terms, and the current handbook governs policy wording; record which source won and why.

Compatibility: provision accounts agent at current versions, plus the HRIS, handbook or onboarding tool the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

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

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

Thread query: API rate limit hit mid-workflow when agent tried to provision accounts for a new hire before day one error failed quota

TL;DR: Fix this in provision accounts agent by acting on the exact problem first: batch the account creation calls per app, cache each app response for the run, space the remaining requests under the rate limit with pauses between batches, and resume the unprovisioned hires from the cache once the quota window resets. Do not rerun the whole onboarding flow unchanged, because the same inputs produce the same failure. Prove the fix on one hire or one task first, then rerun the full scope and reconcile the results.