GitHub Actions "too many requests to the GitHub API" (rate limited in workflow)

Steps that call the GitHub API (gh CLI, github-script, custom actions) share a per-token rate budget. A loop or a busy matrix can exhaust it and start failing with 403/429 rate-limit errors.

What this error means

A step fails with a message about exceeding the API rate limit or too many requests, often after many API calls in a tight loop or across a wide matrix.

Error: You have exceeded a secondary rate limit. Please wait a few minutes before you try again.

Common causes

High call volume on a shared token

Many API calls from one workflow (pagination loops, polling, wide matrices) burn the GITHUB_TOKEN rate budget.

No backoff on retries

A step retries failed calls immediately, compounding the rate-limit pressure instead of backing off.

How to fix it

Reduce calls and back off

1. Batch or cache API results instead of calling per item.
2. Add exponential backoff and respect Retry-After headers.
3. Throttle wide matrices that each hammer the API.

- uses: actions/github-script@v7
  with:
    retries: 3
    script: |
      const prs = await github.paginate(github.rest.pulls.list, { owner, repo });

Let managed runners absorb transient throttling

Managed runner platforms like Latchkey auto-retry jobs that fail on transient secondary rate limits with backoff, so an intermittent throttle does not surface as a hard build failure.

How to prevent it

• Paginate and cache API responses rather than looping calls.
• Always implement backoff that honors Retry-After.
• Avoid wide matrices that each independently hit the API.

Related guides