Github cache limits going to be enforced in November
I got the below email about my github cache usage. It doesn't tell me which repository caused the email but I suspect it is an OTel one since I don't often use personal repositories and none of them show any recent activity.
You can see cache usage here, e.g.
- https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/caches
- https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/caches
These two repos for example show the problem I think GitHub is addressing, which is that they don't seem to be enforcing the limit currently:
Approaching total cache storage limit (392.9 GB of 10 GB Used)
If CI performance tanks once they roll out the LRU eviction, we can definitely ask CNCF if they can increase our cache retention on specific repos.
cc @atoulme who has done some research on GitHub action caching recently
Approaching total cache storage limit (392.9 GB of 10 GB Used)
TIL 393 is "approaching" 10
In the interest of covering the repos i'm responsible for I see the same warning on JS contrib (9.2 of 10) but not on JS. No number given for JS.
I found this overview in the org settings:
| Repository | Cache Usage | Active Caches |
|---|---|---|
| opentelemetry-java-instrumentation | 485 GB | 1243 |
| opentelemetry-go-instrumentation | 110 GB | 432 |
| opentelemetry-collector-contrib | 60.7 GB | 97 |
| weaver | 36.9 GB | 72 |
| opentelemetry-java | 29.9 GB | 366 |
| opentelemetry-ruby | 24.3 GB | 635 |
| opentelemetry-go-contrib | 23.7 GB | 50 |
| opentelemetry-go | 16.6 GB | 86 |
| opentelemetry-php-contrib | 15.6 GB | 1191 |
| opentelemetry-demo | 14.9 GB | 667 |
| opentelemetry-java-contrib | 9.99 GB | 237 |
| opentelemetry-ebpf-profiler | 9.56 GB | 23 |
| opentelemetry-ruby-contrib | 9.54 GB | 194 |
| opentelemetry-js-contrib | 9.2 GB | 81 |
| opentelemetry-java-examples | 8.96 GB | 109 |
| opentelemetry-collector | 8.77 GB | 10 |
| opentelemetry-operator | 8.32 GB | 8 |
| opentelemetry-android | 6.73 GB | 56 |
| opentelemetry-collector-releases | 5.77 GB | 63 |
| opentelemetry-go-build-tools | 5.42 GB | 77 |
| opentelemetry-cpp | 5.17 GB | 10 |
| opentelemetry.io | 4.86 GB | 220 |
| opentelemetry-network | 4.7 GB | 5 |
| semantic-conventions-java | 3.8 GB | 236 |
| opentelemetry-js | 2.44 GB | 36 |
| opentelemetry-dotnet-instrumentation | 2.25 GB | 9 |
| opentelemetry-go-compile-instrumentation | 2.03 GB | 58 |
| opentelemetry-injector | 1.78 GB | 63 |
| opentelemetry-ebpf-instrumentation | 1.59 GB | 54 |
| opentelemetry-php | 1.4 GB | 74 |
| opamp-go | 1.2 GB | 13 |
| opentelemetry-lambda | 1.14 GB | 24 |
| opentelemetry-proto-java | 1.09 GB | 34 |
| opentelemetry-configuration | 567 MB | 80 |
| opentelemetry-erlang | 118 MB | 10 |
| semantic-conventions | 16.8 MB | 19 |
| opentelemetry-helm-charts | 4.06 MB | 1 |
| build-tools | 968 KB | 1 |
^^ cc @open-telemetry/java-instrumentation-maintainers @open-telemetry/go-instrumentation-maintainers @open-telemetry/collector-contrib-maintainers @open-telemetry/weaver-maintainers @open-telemetry/java-maintainers @open-telemetry/ruby-maintainers @open-telemetry/go-maintainers @open-telemetry/php-maintainers @open-telemetry/demo-maintainers
Just to make sure I'm understanding this correctly, we don't need to take any action, but should keep an eye on our CI speed to see if we'd like to increase the cache once the new policy takes effect?
Just to make sure I'm understanding this correctly, we don't need to take any action, but should keep an eye on our CI speed to see if we'd like to increase the cache once the new policy takes effect?
👍
@kaylareopelle or take corrective actions to how you manage caches, such as using caches with keys that don't allow reuse. Some discussions in the github maintainers forum here: https://github.com/community/maintainers/discussions/606 (with the Github actions PMs involved) and my own research thread here: https://github.com/community/maintainers/discussions/581
@atoulme how can I have access to those discussions? I got 404 in both links.
just fyi, enforcement date has been moved back from mid-October to November:
https://github.blog/changelog/2025-09-29-new-date-for-enforcement-of-cache-eviction-policy/
Can we increase the limits for the following repos?
- opentelemetry-go-instrumentation
- opentelemetry-go-contrib
- opentelemetry-go
hi @pellared, I'll open a CNCF ticket to ask about this, what would you like the limit to be for each one?
After this date, all repositories will receive 10GB for free and have the option to pay for additional storage at a per GB/month rate that is checked at hourly intervals.
I can't find anything in GitHub documentation about paying for additional storage, so I suspect they haven't released that capability yet (and maybe why they pushed back the enforcement date)
Looks like it's happening now:
https://github.blog/changelog/2025-11-20-github-actions-cache-size-can-now-exceed-10-gb-per-repository/
Found this new setting:
fwiw, there hasn't been a noticeable change in the opentelemetry-java-instrumentation CI times since this went into effect (haven't checked any other repos, but that was the repo with the largest cache usage previously)