GitHub Actions "Failed to restore: Cache service responded with 503"

By Kaveh Alemi·Latchkey

The Actions cache backend returned a 503 (unavailable) or 429 (throttled), so the restore or save failed; this is a transient service-side condition, not a problem with your key.

What this error means

A cache step warns "Failed to restore: Cache service responded with 503" or 429. The job continues without the cache, so dependent steps run cold and slower.

Warning: Failed to restore: Cache service responded with 503

Common causes

Transient cache backend outage

The cache service was briefly unavailable (503) and rejected the request.

Rate limiting under load

A burst of cache traffic from a wide matrix triggered 429 throttling.

How to fix it

Tolerate the transient failure

1. Re-run the job; cache 503/429 errors are usually transient.
2. Reduce concurrent cache calls from very wide matrices.
3. Ensure the build still succeeds (slower) on a cache miss.

Use auto-retrying managed caching

Latchkey managed runners auto-retry transient infrastructure failures including cache-service 503/429 responses, and run on warm, right-sized capacity, at roughly 70% less than GitHub-hosted runners.

How to prevent it

• Treat 503/429 cache errors as retryable, not fatal.
• Keep builds correct (just slower) on a cache miss.
• Avoid hammering the cache from huge concurrent matrices.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions