GitHub Actions
●LOW●CI/CD●BEGINNERGitHub Actions Cache Restore Failure
A workflow's cache step reports a miss every run, so dependencies reinstall from scratch instead of restoring.
Est. Time
15 minutes
Version
v1.0.0
Updated
7/27/2026
Author
AutoDeploy Team
Tags
Prerequisites
- ✓ A GitHub Actions workflow using actions/cache
Setup Guide
Download guideGitHub Actions Cache Restore Failure
Problem
A workflow's cache step reports a cache miss every run (or fails outright), so dependencies reinstall from scratch instead of restoring from cache.
Symptoms
- Cache not found for input keys
- Every run shows a cache miss regardless of whether dependencies actually changed
- actions/cache errors with a permissions or size-limit message
Root Cause
The cache key doesn't match between runs (often derived from something that changes every run, like a timestamp or full commit SHA instead of a lockfile hash), the cache was evicted (7 days unused, or the repo's 10GB total cache cap), or the workflow lacks permission to write to the cache (common on PRs from forks).
Solution
1. Base the cache key on a lockfile hash, not something that changes every run
- uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ hashFiles('package-lock.json') }}
restore-keys: npm-2. Check the repo's Actions → Caches page for evictions or size limits
3. Add a restore-keys fallback so a partial match still saves reinstall time
restore-keys: | npm-
4. Remember forked-repo PRs can't write to the base repo's cache — this is expected, not a bug
5. For monorepos, scope the cache path and key per package so unrelated changes don't invalidate everything
Prevention
- Key caches off lockfile hashes, never off run-specific values
- Keep cache paths as narrow as possible — just the package manager's store, when supported
- Set up restore-keys fallbacks for graceful partial hits
- Periodically check total cache usage against the 10GB repo cap
References
Last updated on 7/27/2026 · Part of the AutoDeploy DevOps Documentation library