The Cache@2 task could not restore or save the cache. A key/path mismatch causes a miss, while a backend timeout or oversized cache causes a transient failure that usually succeeds on retry.
What this error means
The cache step warns it could not restore (a miss, which is harmless) or errors out saving with a network/timeout message. Restore misses are expected on first run; storage-backend errors are transient and clear on a re-run.
Azure DevOps
##[warning]Cache restore failed.
##[error]Failed to save cache: Request timeout while uploading cache to
the service. Please retry.
Common causes
Key or path mismatch (a plain miss)
A cache key that includes a changing hash, or a path that does not exist yet, produces a restore miss. This is normal on the first run and after a lockfile change.
Transient backend timeout or oversized cache
Uploading a very large cache, or a brief Azure Artifacts cache backend blip, can time out the save. These are transient and clear on retry.
How to fix it
Use a stable key with sensible fallbacks
Key on the lockfile so restores hit, with a restore-key fallback for partial hits.
Backend timeouts are transient; a re-run of the job usually succeeds. Trim the cached path if it is excessively large.
How to prevent it
Key caches on the lockfile, not a volatile value.
Cache only what is expensive to rebuild to keep the cache small.
Treat occasional backend timeouts as transient and rely on retry.
Frequently asked questions
What causes ""Cache restore failed""?
A cache key that includes a changing hash, or a path that does not exist yet, produces a restore miss. This is normal on the first run and after a lockfile change.
How do I fix "Cache restore failed"?
Key on the lockfile so restores hit, with a restore-key fallback for partial hits.
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.
