GitHub Actions "Cache service responded with 5xx" - Transient Cache Errors
By Kaveh Alemi·Latchkey
The GitHub cache backend returned a transient 5xx while saving or restoring. This is an infrastructure blip, not a problem with your workflow, and usually clears on retry.
What this error means
A Restore or Save cache step logs "Cache service responded with 500" (or 503), and sometimes the whole job fails over a cache operation that has nothing to do with your code.
Actions log
Warning: Failed to restore: Cache service responded with 503
# or
Error: Cache service responded with 500 during upload chunk
Common causes
Transient cache backend failure
The cache service occasionally returns 5xx during incidents or load. The operation typically succeeds on a later run with no change.
Caching treated as fatal
If a cache miss or save error aborts the job, a transient backend blip turns into a red build even though the real work could proceed.
How to fix it
Make caching non-fatal
Caching is an optimization; do not let a cache error fail the job. Continue on cache errors and let the build proceed cold.
Because 5xx from the cache service is transient, re-running the job usually succeeds without any change.
How to prevent it
Add continue-on-error to cache steps so a blip never fails the build.
Keep the build correct without the cache so a cold run still works.
Retry on transient cache-service 5xx.
Frequently asked questions
What causes ""Cache service error""?
The cache service occasionally returns 5xx during incidents or load. The operation typically succeeds on a later run with no change.
How do I fix "Cache service error"?
Caching is an optimization; do not let a cache error fail the job. Continue on cache errors and let the build proceed cold.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.
