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

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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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