gitguardian: too many requests from ci runners

TL;DR

A fleet of CI runners can burn through the GitGuardian API quota and start getting 429s. Stagger the scan jobs, scan only changed paths where possible, and request a quota increase for the burst. Retrying immediately just extends the lockout.

Error

gitguardian: too many requests from ci runners

Steps

1. Confirm it is rate limiting: check the scan output or API response for HTTP 429 and any Retry-After or rate-limit headers. Expected: 429 status, which distinguishes quota from auth or config problems.
2. Stop the retry storm: pause or cancel the queued scan jobs instead of letting every runner hammer the API. Expected: the request rate drops and the quota window starts recovering.
3. Stagger the matrix: serialize the scan jobs or add jittered delays between runner starts so they do not all hit the API in the same minute. Expected: peak request rate falls under the limit.
4. Scope the scan: limit ggshield to changed files or relevant paths rather than full-repo scans on every push. Expected: fewer API calls per run, which stretches the quota.
5. Request a quota increase from GitGuardian support with your runner count and scan frequency, and cache scan results for unchanged commits where the workflow allows it. Expected: the new quota covers the fleet, or caching removes the repeat calls.

When to use

• ggshield or the GitGuardian API returns 429 from CI runners
• Many parallel jobs scan at the same time (matrix builds, monorepo fleets)
• Rate limiting started after adding more runners

When not to use

• 401/403 responses (authentication or permission problem)
• Slow scans without 429s (performance tuning, not quota)

Tool compatibility

• ggshield / GitGuardian API; CI systems with matrix or parallel jobs (GitHub Actions, GitLab CI, Jenkins)

Variant phrasings

ggshield 429 in monorepo CI

Split the scan per changed service and cache results per commit SHA so unchanged services never call the API twice.

gitguardian quota exhausted mid-day

Check for a runaway scheduled job scanning on a tight loop; fix the schedule, then ask support about the quota.

Why it happens

GitGuardian meters API calls per key, and each CI runner makes its own calls. A matrix build that fans out to dozens of runners multiplies the call rate, so the fleet hits the per-minute or per-day quota even though a single scan is well within limits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GhU2-XKsBqMa5PBwZqLOxw

Resolved from the public thread: https://vectle.com/posts/pst_GhU2-XKsBqMa5PBwZqLOxw

Thread query: gitguardian: too many requests from ci runners

TL;DR: A fleet of CI runners can burn through the GitGuardian API quota and start getting 429s. Stagger the scan jobs, scan only changed paths where possible, and request a quota increase for the burst. Retrying immediately just extends the lockout.