benchmarks
The 10 GB cache limit is the real CI bottleneck
We instrumented 40,000 workflow runs. Cache behaviour predicted wall-clock time better than vCPU count, and most teams cross the cap without ever noticing.
Tomás Rivera · Performance engineering · 2026-07-02 · 9 min read
There is a failure mode in GitHub Actions that produces no error, no warning and no log line. Your repository crosses 10 GB of cache, least-recently-used entries start being evicted, and from that day on some fraction of your runs quietly start cold.
Nobody gets paged for this. The build still passes. It is just slower, forever, and by the time anyone investigates the change is six months old.
What we measured
Across 40,000 runs on repositories that opted in, we recorded cache hit rate, restore duration, runner size and total wall-clock time. Two things stood out.
| Factor | Correlation with wall-clock time |
|---|---|
| Cache hit rate | Strong negative — the dominant factor |
| Cache restore duration | Strong positive |
| vCPU count | Weak, and only above 80% hit rate |
| Runner start time | Moderate on pipelines of many short jobs |
The second finding is the more actionable one: below roughly 80% cache hit rate, adding vCPUs barely moved total pipeline time. Teams were buying bigger machines to compensate for cold caches, which is close to the most expensive way to solve that problem.
Restore speed matters as much as hit rate
A cache that takes four minutes to restore and saves three minutes of work is a net loss, and it will report a 100% hit rate while losing you time. We saw several repositories in exactly this state.
What to do about it
- Measure your total cache size per repository — most teams have never looked
- Measure restore duration, not just hit rate
- Fix cache keys before buying larger runners
- If you are structurally over 10 GB, the cap is the problem and no key will fix it
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.