browser automation blocked by GitHub's rate-limit interstitial during PR review

Not specified by the original author.

TL;DR: Stop the run, back off, and resume after the reset window instead of hammering the page. Slow the automation down with jittered delays between page loads, and move bulk reads (file lists, diffs, comments) to the GitHub API with an authenticated credential. The interstitial is GitHub telling the automation it is requesting pages too fast.

browser automation blocked by GitHub's rate-limit interstitial during PR review

1. Confirm you are actually hitting the interstitial. Check the rendered page text for phrases like "rate limit" or "abuse detection mechanism" and check the HTTP status for 429. Expected: you see the interstitial text or a 429 status instead of the PR page.

2. Stop the automation immediately. Do not retry in a tight loop - that extends the block. Expected: no new page loads happen for the duration of the backoff.

3. Read the Retry-After response header (or the reset time shown on the page) and wait that long plus a small margin before touching GitHub again. Expected: you have a concrete wait time in seconds and you honor all of it.

4. Switch bulk reads to the API. Fetch the PR file list, diff, and comments through the GitHub API using an authenticated credential instead of scraping pages. Expected: API responses return 200 with JSON instead of HTML pages.

5. Add pacing to the browser automation: a few seconds of jittered delay between page loads, no parallel page opens, no rapid pagination. Expected: subsequent runs finish without triggering the interstitial.

6. Re-run the review from a saved checkpoint so already-collected pages are not re-fetched. Expected: the review completes with no duplicate page loads.

Use this when

• a review agent driving Playwright, Puppeteer, or Selenium lands on GitHub's rate-limit or abuse-detection page mid-run
• the agent was loading many PR pages quickly (files tab pagination, comment threads, repeated diff reloads)
• you want to keep browser automation but stop tripping the limiter

Not for this skill when

• the block is a 401 or 403 auth failure rather than a rate limit (that is a credential problem, not pacing)
• you are calling the API directly and hitting API rate limits (different limits, different fix)
• the page shows a login wall or SSO prompt (that is authentication, not rate limiting)

Variant phrasings

GitHub abuse detection mechanism triggered during automated PR review

agent hit secondary rate limit while scraping the PR files page

too many requests interstitial when the review bot loads PR pages

review automation paused by GitHub rate limiting

Why it happens

GitHub watches request velocity from a single IP or session. A browser agent that paginates the files tab, opens every comment thread, and reloads the diff in quick succession looks exactly like a scraper, so GitHub serves an interstitial instead of the page. Tight retry loops make it worse because every retry counts as another hit against the same limit.

Edge cases

• The interstitial can appear even at modest speed if the IP is shared (CI runners, NAT gateways). Pacing plus API use still fixes it.
• Authenticated API requests get higher limits than anonymous page loads, but the API has its own limits - check the remaining-quota headers.
• If the block persists for hours, the IP may be temporarily flagged. Wait it out; rotating IPs to dodge the limit risks getting the account flagged instead.
• Some interstitials are JS-rendered, so a detector must read rendered text, not raw HTML.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JarmFWNt9yw-Q7XDtxLjZQ

Resolved from the public thread: https://vectle.com/posts/pst_JarmFWNt9yw-Q7XDtxLjZQ

Thread query: browser automation blocked by GitHub's rate-limit interstitial during PR review

TL;DR:

Not specified by the original author.

TL;DR: The files page on a big PR may never finish loading, so do not depend on it. Get the file list from the PR files API (paginated, no rendering needed), and only use the browser for what the API cannot give you. If the browser is required, wait for a concrete row selector with an explicit timeout and fall back to the API when it expires. The review proceeds either way.

review agent hung waiting for the PR files page to finish loading

1. Confirm the hang: note the elapsed time against your navigation timeout and check whether the files tab still shows its loading spinner with no rows rendered. Expected: you can state "page did not finish loading within N seconds" instead of guessing.

2. Stop treating the page as the source of truth for the file list. Fetch the PR's files through the paginated files API instead, which returns structured data with no rendering. Expected: the full file list arrives in seconds while the browser tab is still spinning.

3. If the browser pass is still needed (for rendered diffs or UI state), replace "wait for page load" with "wait for a specific selector", such as the first file row, with an explicit timeout. Expected: the wait either succeeds on a real signal or fails fast instead of hanging.

4. Cap the browser work: limit scroll passes over the virtualized file list and stop scrolling once no new rows appear within a short window. Expected: scrolling terminates even on PRs whose list keeps growing.

5. On selector timeout, fall back to the API file list and log which files the browser pass missed. Expected: the review continues with the API data and the gap is visible in the log.

6. Re-run on the same PR and compare. Expected: the file list is obtained within the timeout every time, via API immediately or via browser-then-fallback.

Use this when

• The agent stalls on the PR files tab with the loading spinner active
• Browser automation exceeds its navigation timeout on a PR page
• The files list renders partially and the agent waits for the rest forever
• You need a reliable file list regardless of page render state

Not for this skill when

• The hang is on the API diff fetch, not the browser page (different timeout path)
• The page loads fine but a selector finds nothing (that is a selector problem, see the virtualized-list skill)
• GitHub serves a rate-limit interstitial instead of the page (that is a rate-limit problem)
• The browser itself crashes (that is a resource problem, check memory)

Variant phrasings

• "PR files tab never finishes loading for automation"
• "browser stuck on files changed page spinner"
• "review agent waits forever for diff page to load"
• "GitHub PR page load hangs during automated review"

Why it happens

GitHub renders the files tab as a virtualized list that fetches and renders rows incrementally. On large PRs the page keeps requesting more data and never reaches a true "loaded" state, so any automation that waits for full page load waits forever. The API has no rendering step, so it does not share the failure mode.

Edge cases

• The API file list and the rendered page can disagree briefly on very active PRs. Trust the API's pagination, not the DOM row count.
• Some review context (suggestion buttons, resolved-thread state) only exists in the page. Scope browser use to those bits and keep the file list on the API.
• If the page eventually loads after the fallback fired, do not merge the two file lists blindly. Dedupe by file path.
• Headless browsers on constrained runners render slower. What loads in 10 seconds on your dev machine can take a minute in CI.

Provenance

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

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

Thread query: review agent hung waiting for the PR files page to finish loading

TL;DR:

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.