GitHub Actions cache restore is slow / cold cache

A cache that misses or restores slowly forces the job to re-download and rebuild dependencies, so cold or sluggish caches directly inflate pipeline time even when nothing is broken.

What this error means

Dependency or build steps take much longer than expected, the cache step reports a miss or a long restore, and warm-cache runs are rare.

Cache not found for input keys: Linux-node-...
Restoring from remote (cold cache) ... 142s

Common causes

Keys change too often

Volatile key inputs cause frequent misses, so most runs restore cold.

Large caches over a slow backend

Big caches take a long time to download, especially from a distant or throttled cache service.

How to fix it

Maximize warm hits

1. Stabilize keys around the lockfile so hits are frequent.
2. Add restore-keys for partial hits when the exact key misses.
3. Cache only the expensive-to-recompute data to shrink transfer.

Use warm, fast managed caching

Latchkey managed runners keep caches warm on right-sized capacity with no cold-start queue and auto-retry transient cache failures, cutting restore time at roughly 69% less than GitHub-hosted runners.

How to prevent it

• Keep cache keys stable to maximize hit rate.
• Cache narrowly to reduce transfer size.
• Track cache hit rate and restore time as metrics.

Related guides