github API error: API rate limit exceeded for user ID on unauthentica

Not specified by the original author.

TL;DR

Unauthenticated GitHub search hits the harsh anonymous rate limit fast. Authenticate the requests (even a token with no scopes) to get the higher quota, and cache results.

Error

API rate limit exceeded for user ID (anonymous search)

Steps

1. Add a personal access token to the search requests Expected: the quota jumps to the authenticated tier.
2. Cache search results for repeated queries Expected: fewer calls overall.
3. Spread paginated fetches over time if you still hit limits Expected: no more 429s.
4. Monitor the rate-limit headers Expected: you see the budget before it runs out.

When to use

• Rate limit exceeded on GitHub search
• The requests are unauthenticated

When not to use

• Authenticated and still limited (then you need to slow down or use conditional requests)
• It is the secondary rate limit (then reduce concurrency)

Tool compatibility

• GitHub API rate limits
• Code search tooling

Variant phrasings

github search rate limit exceeded

Authenticate. Anonymous search quota is tiny.

api rate limit for user id

Same: add a token, even one with no scopes.

Why it happens

Search feels like browsing, so agents skip auth. GitHub's anonymous search quota is deliberately tiny.

Edge cases

• Search has stricter limits than the core API; plan accordingly
• Tokens in CI need only public_repo scope for public search

Provenance

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

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

Thread query: github API error: API rate limit exceeded for user ID on unauthenticated search

TL;DR: Unauthenticated GitHub search hits the harsh anonymous rate limit fast. Authenticate the requests (even a token with no scopes) to get the higher quota, and cache results.

Not specified by the original author.

TL;DR

Wait for the reset window, then cut the call volume: cache responses per run, page efficiently, and replace N+1 REST calls with batched GraphQL where possible. The bot hit the 5,000-requests-per-hour authenticated quota; the immediate fix is backing off until reset, the lasting fix is making fewer calls.

The error

"API rate limit exceeded for user ID": review bot blocked mid-CI

Steps to fix

1. Confirm it's the primary rate limit: inspect the 403 response headers for a zero remaining count and a reset timestamp - plan the retry for after that time.

   • Expected: the headers name a reset time, usually within the hour.

2. Add retry logic that sleeps until the reset time on rate-limit 403s instead of failing the run.

   • Expected: the next run survives a limit hit by waiting rather than crashing.

3. Cut call volume: cache PR metadata for the duration of the run, request only the fields you need, and replace per-file REST fan-out with one GraphQL query where possible.

   • Expected: the same review completes in a fraction of the API calls.

4. Re-run after the reset.

   • Expected: the run completes; watch the remaining-quota header to confirm headroom.

Use this when

• A review bot dies mid-run with "API rate limit exceeded for user ID".
• The job reviews large PRs with per-file or per-comment API calls.
• CI runs many review jobs concurrently under one credential.

Not for this skill when

• The 403 is a secondary rate limit (abuse detection from concurrency, not total count) - lower parallelism instead.
• Calls are unauthenticated (60 per hour) - authenticate first.
• The limit is on a different API (e.g. the search API has its own lower quota).

Variant phrasings

• github api rate limit exceeded review bot
• review action blocked rate limit mid CI
• API rate limit exceeded for user ID github actions
• bot hit github rate limit during PR review

Why it happens

GitHub allows 5,000 REST requests per hour per authenticated user (or per app installation). Review bots that fetch every file, comment, and check status individually on big PRs - especially when several jobs share one credential - can burn through that quota in a single run. The limit is per credential, not per repository, so one busy bot starves everything else using the same token.

Edge cases

• Secondary rate limits trigger on request concurrency, not total count: a highly parallel bot gets blocked with quota to spare - throttle concurrency.
• Unauthenticated calls get 60 per hour; a missing auth header turns a working bot into a failing one instantly.
• GitHub Enterprise Server limits are set by the instance admin and may be lower than github.com.
• Splitting work across multiple bot credentials multiplies the quota but complicates auditing - prefer fewer calls first.

Provenance

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

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

Thread query: "API rate limit exceeded for user ID": review bot blocked mid-CI

TL;DR: Wait for the reset window, then cut the call volume: cache responses per run, page efficiently, and replace N+1 REST calls with batched GraphQL where possible. The bot hit the 5,000-requests-per-hour authenticated quota; the immediate fix is backing off until reset, the lasting fix is making fewer calls.

Not specified by the original author.

TL;DR

The review job is calling the API faster than the installation's hourly budget allows. Find the hot loop, cache repeated reads, back off on 403s, and fetch less per call. The quota is per installation per hour, so every redundant call counts.

The error

API rate limit exceeded for installation ID failed the review run: how to fix
403: You have exceeded a secondary rate limit. Please wait a few minutes before you try again.

Steps

1. Find the hot loop in the run logs

Look at which endpoints the review job called and how many times. Expected output: one or two endpoints dominate, usually repeated GETs for the same PR data on every retry.

2. Cache repeated reads

Store PR metadata, file lists, and diffs after the first fetch and reuse them for the rest of the run. Expected output: the same logical review makes a fraction of the API calls.

3. Add exponential backoff with jitter on 403 and 429

When the API says slow down, wait and retry with growing delays plus random jitter. Expected output: transient limit hits recover instead of failing the run.

4. Fetch less per call

Use pagination sensibly, request only the fields needed, and avoid polling loops that re-list unchanged resources. Expected output: lower call volume for identical review coverage.

5. Watch the rate-limit headers on the next run

Check x-ratelimit-remaining in the logs after the fix. Expected output: the remaining budget stays comfortably above zero through the whole run.

When to use

• A review run fails with rate limit exceeded for the installation ID
• Retries of the same job fail faster each time
• The logs show hundreds of API calls for one PR

When not to use

• Authentication failures (bad credentials, expired installation token)
• Pure secondary abuse limits from concurrent jobs (stagger the jobs instead)
• GraphQL complexity errors (restructure the query)

Tool compatibility

• GitHub REST API v3 rate limits for GitHub App installations
• Applies to reviewdog, custom review bots, and CI jobs using an installation token
• Same discipline helps on GitHub Enterprise with its own limits

Variant phrasings

rate limit exceeded for user ID instead of installation ID

The job is authenticating as a user, not an installation. User quotas are smaller; switch to installation auth or cut calls the same way.

secondary rate limit on a review job

Too many concurrent requests, not too many total. Add concurrency limits and jitter rather than just caching.

review job passes on retry but fails on first run

The first run does the expensive full fetch. Cache the results as artifacts so retries and re-runs start warm.

Why it happens

Installation tokens share one hourly quota across everything that installation does. A review job that refetches the PR diff, file list, and comments on every step, and then retries the whole job on failure, multiplies its call count until the quota is gone. The API is not broken; the job is just chatty.

Edge cases

• One installation shared across many repos: the quota is shared too. Split heavy repos onto separate installations.
• Webhook bursts (many PRs at once): queue the review jobs instead of running them all concurrently.
• Long-running review agents: refresh cached data on a timer rather than refetching per decision.

Provenance

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

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

Thread query: API rate limit exceeded for installation ID failed the review run: how to fix

TL;DR: The review job is calling the API faster than the installation's hourly budget allows. Find the hot loop, cache repeated reads, back off on 403s, and fetch less per call. The quota is per installation per hour, so every redundant call counts.