actions/cache "Cache service responded with 429" in CI

By Daniel Zoghalchali·Latchkey

A 429 from the cache service means the backend throttled the request because many jobs uploaded or downloaded caches simultaneously. It is transient: the action retries, and on a temporary spike the failure usually clears on a re-run.

What this error means

The Restore or Save step warns "Cache service responded with 429" (Too Many Requests), often during large matrix runs, then either retries or skips the cache for that job.

Warning: Failed to restore: Cache service responded with 429

Common causes

A burst of concurrent cache operations

A wide matrix or many simultaneous workflow runs hammer the cache service in a short window and trip rate limiting.

Repeated large cache uploads in a short period

Frequently re-uploading big caches across many jobs concentrates load and raises the chance of a 429.

How to fix it

Re-run the job; 429 is transient

A single 429 rarely repeats. Re-run the failed job, and if it is a flaky save, the next run reserves and uploads normally.

Reduce concurrent cache pressure

1. Limit matrix width or stagger heavy cache jobs with max-parallel.
2. Cache fewer, smaller paths so each operation is lighter.
3. Share one warmed cache via restore-keys instead of every leg saving its own.

strategy:
  max-parallel: 4
  matrix:
    python: ['3.10', '3.11', '3.12', '3.13']

How to prevent it

• Keep matrix width reasonable to limit simultaneous cache calls.
• Cache smaller paths so each upload finishes quickly.
• Re-run transient 429s rather than treating them as real failures.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions