Repository navigation
Time sensitive: GitHub Actions Cache rate limits (from GitHub staff) #61436
Description
Activity
CC @nodejs/build
sccache / opendal::services::Ghac should already be honouring rate limiting AFAIA.
As for cache size, the cache eviction time right now is about a day, although I imagine there are circumstances (eg. concurrent builds from multiple different release branches) that might push us close to the limit.
As for cache size, the cache eviction time right now is about a day, although I imagine there are circumstances (eg. concurrent builds from multiple different release branches) that might push us close to the limit.
@Renegade334 - the reason I'm reaching out is because sccache and opendal need to make a few adjustments to fully honour our rate limiting. These rates have been very recently introduced. I've already contacted them to adjust their implementation.
You are flagged in our system as one of the highest repos to exhibit thrashing behaviour. Cache eviction happens near realtime right now, and cache entries are no longer held for 24 hours before eviction as was the case in the legacy service. You're dealing with a re-written service that is much more performant.
I would highly advise you to increase you cache storage limits to > 10GB to reduce your thrashing levels and upgrade your workflows when sccache pushes a new release with the fixes we asked for.
Reacted by René, Marco Ippolito and DHRUV KAUSHIKTSC – based on #61436 (comment), it sounds like a decision needs to be made re. paying for further GHA cache capacity.
This is too early for TSC agenda. Investigation must be done first on at least:
- Potential optimizations to the workflows so we don't explode the limits
- What capacity is needed and what will be the associated cost
These are not questions that the TSC can answer during a meeting and I don't see how we can make a decision without the answers.
It seems no one is working on it yet, so tagging it as help wanted. (tagging TSC won’t help much - TSC is just another group of volunteers that may only step up to do something when there’s absolutely nobody else who wants to work on it, better check if anyone is interested to help before falling back to the last resort).
- added a commit that references this issue
on Jan 23, 2026 We have a limit of 10GB set at the enteprise layer. I'll investigate how to raise this.
@Link- can you clarify what the exact problem with caching is that impacts us? Your messages are a bit generic and not immediately actionable (minus increasing the cache size).
cc @bensternthal for visibility
@bensternthal @Link- can you please verify if we can raise the limit and if we would incur in any costs associated?
@mcollina acknowledged and looking into it.
@mcollina We are able to update both the cache retention and cache size eviction limit. Can you let me know what changes you need. With this I can understand the cost.
And if this is blocking work, we can increase this now and sort out costs etc later.
Note I do not think this would be cost prohibitive for example doubling this to 20GB would be $0.70/month maximum (per repository I think).
21 remaining items
- added 10 commits that reference this issue
on Feb 19, 2026 - added 2 commits that reference this issue
on Feb 24, 2026 With the combination of #61790 and the 20GiB cache size, we seem to be OK now.
The period of cache overgrowth can be ignored (#61436 (comment)), but the periods before and after this hump correspond with before and after limiting sccache to the main branch, and we don't appear to be threatening the danger zone since.
Notwithstanding the bits mentioned in #61436 (comment), I think this is probably OK to close.
Reacted by Matteo CollinaReacted by Antoine du HamelThanks for the work folks!
To preserve the health of our services and reliably serve all GitHub Actions Cache users, the following rate limit will take effect immediately:
200 cache entry uploads per minute per repository.
If you exceed this limit, you will receive a 429 response and an error message indicating that you have exceeded the rate limit.
You should not retry your request until after the time specified in the
Retry-Afterheader has passed. If your request continues to fail due to this rate limit, implement exponential backoff between retries, and throw an error after a specific number of retries.This limit helps prevent abuse and denial-of-service attacks and ensures that the service remains available for all users.
Important
Introduce the needed changes to your library so that the rate limit errors are retried as per the recommended schedule.
Update your actions and libs
If you are using any of the following actions or depend on any of these libraries:
Introduce the needed changes to maintain a high cache hit/miss ratio, or follow-up with the authors of those libraries on the progress of these changes.
Thrashing
It has also come to our attention that a substantial number of repositories adopting this library (or action) are exhibiting consistent cache thrashing behavior.
Cache thrashing occurs when cache entries are frequently evicted and re-created in a continuous cycle, preventing effective cache utilization. This happens when your workflow generates more cache data than can be stored within your available cache storage quota.
By default, GitHub Actions provides 10 GB of cache storage per repository. When this limit is reached, GitHub automatically evicts the least recently used cache entries to make room for new ones. If your workflows consistently produce cache data that exceeds this limit, the cache is constantly being written and evicted—resulting in thrashing.
This leads to:
To avoid thrashing, consider increasing your cache storage limit. For more information, see "Usage limits and eviction policy."