Skip to content
Latchkey

GitHub Actions Cache From Another Workflow Run Not Restored

A cache saved in one run is not restored in another because cache access is scoped by branch. A run can read caches from its own branch and the base/default branch - but not from unrelated feature branches.

What this error means

A feature-branch run misses a cache that a different feature branch populated, even with the same key, because cache scoping does not share across sibling branches.

Actions log
# branch feature/a saved key deps-abc123
# branch feature/b run misses it -> rebuilds
Cache not found for input keys: deps-abc123

Common causes

Cache scope is per branch

Caches are scoped to the branch that created them, plus read access to the base and default branch. A different feature branch cannot read another feature branch’s cache.

Expecting a global cache

Assuming any run can read any cache by key ignores the branch-scoping rule, so cross-branch reuse silently misses.

How to fix it

Seed the cache on the default branch

Run the cache-producing workflow on the default branch so feature branches inherit it via base-branch read access.

.github/workflows/warm-cache.yml
# a scheduled/push job on the default branch warms the cache
on:
  push:
    branches: [main]
# feature branches then restore it via base-branch scope

Use restore-keys for partial hits

  1. Add restore-keys prefixes so a near-match from the base branch still helps.
  2. Warm shared caches on the default branch, not on feature branches.
  3. For cross-run artifacts (not deps), use artifacts with run-id download instead.

How to prevent it

  • Warm shared caches on the default branch so all branches can read them.
  • Use restore-keys prefixes to survive key changes and branch scoping.
  • Do not expect sibling feature branches to share each other’s caches.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →