GitHub Actions "Cache not found for input keys" - Fix actions/cache Misses

By Daniel Zoghalchali·Latchkey

actions/cache found no entry for your key. Usually the key changes on every run (so nothing ever matches), or there is no restore-keys fallback for a partial match.

What this error means

The Restore cache step logs "Cache not found for input keys" and the job rebuilds dependencies from scratch every time, even when nothing changed.

Actions log

Cache not found for input keys: npm-2f9c1a3b...
# next run uses a different hash, so it never hits

Diagnose it: was the cache hit, and was it the right one?

Cache bugs split into three shapes and they need different fixes: the cache never saved, it saved but the key never matches on restore, or it restored a stale entry through a restore-keys prefix and is now poisoning the build. The step output tells you which one you have.

.github/workflows/ci.yml

- uses: actions/cache@v4
  id: cache
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

- name: What happened
  run: |
    echo "exact hit: ${{ steps.cache.outputs.cache-hit }}"
    echo "key used:  ${{ steps.cache.outputs.cache-matched-key }}"

Common causes

Key changes on every run

A key built from github.sha or a timestamp is unique per run, so a restore can never match a prior save.

No restore-keys fallback

Without restore-keys, an exact-key miss falls all the way through instead of restoring a recent partial match.

Cache never saved on the base branch

Caches are scoped by branch; a PR can read the base/default-branch cache, but if nothing saved it there first, there is nothing to restore.

How to fix it

Key on the lockfile, not the SHA

Hash the dependency lockfile so the key is stable across runs that did not change dependencies, and add a restore-keys prefix.

.github/workflows/ci.yml

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      npm-

Seed the cache on the default branch

Run the workflow on the default branch once so a cache is saved for PRs to restore.
Confirm the save step actually ran (it is skipped on an exact-key hit).
Keep the path the same between save and restore.

Cache limits that produce confusing failures

Repository cache is capped at 10 GB. Past that, GitHub evicts least-recently-used entries, so a large cache can silently stop persisting.
Caches are scoped by branch. A cache written on a feature branch is not visible to another feature branch, only to its base and its own descendants.
An entry not read for 7 days is evicted, so a rarely-run workflow effectively never has a warm cache.
Restoring a cache built for a different tool version is worse than a cold start, because you get a corrupted tree instead of a clean install. Always include the tool version in the key.

How to prevent it

Build cache keys from lockfile hashes, never from the commit SHA.
Always provide restore-keys for partial-match fallback.
Prefer setup-* actions with built-in caching where available.

Frequently asked questions

What causes GitHub Actions "Cache not found for input keys"?

There are 3 common causes: key changes on every run, no restore-keys fallback, and cache never saved on the base branch. A key built from github.sha or a timestamp is unique per run, so a restore can never match a prior save.

How do I fix GitHub Actions "Cache not found for input keys"?

There are 2 fixes depending on which cause you have: key on the lockfile, not the sha and seed the cache on the default branch. Work through them in order, since the first is the most common.

What does GitHub Actions "Cache not found for input keys" actually mean?