Fix GitHub Actions Cache 503 and 429 Errors

DEV Community

Cache service responded with 503 or 429 in GitHub Actions

Cache service responded with 503 in GitHub Actions is the Actions cache backend refusing one request, and a 429 is the same backend throttling you. Neither is a problem with your key: the step warns, the job carries on without a cache, and the only thing that turns it into a red build is a workflow that treats a cache miss as fatal. The restore failing is a warning. A red build needs something else in the workflow to insist that the cache was essential. What this error means A cache step logs a warning rather than an error, and the job keeps going: "Warning: Failed to restore: Cache service responded with 503". A 429 appears in the same shape and means the opposite thing, that the service is working and has decided you are asking too often. Either way the restore did not happen, so the steps after it run cold: the install downloads everything, the build has no incremental state, and the job takes the long route. The save at the end of the job can fail the same way, which is worse in one specific sense, because the next run then starts cold too. The block below is a sample from the pattern library rather than from a run of ours, and the section on reproduction explains why there is no run on this page. ```Sample log from the pattern library Warning: getCacheEntry failed: Cache service responded with 503

Common causes

The cache service had a bad few minutes

The ordinary case. A 503 is the backend declining one request during an incident, a deploy or a load spike, and it clears on its own. Nothing in the workflow caused it and nothing in the workflow will prevent it; the only useful response is to make sure it costs a slower build rather than a failed one.

You set continue-on-error and the job still failed

The wasted fix, because the tolerance went on the step that was already tolerant. The cache step warns; the failure is in whatever ran next on the assumption that the cache was restored. Look for a step gated on the cache-hit output, a fail-on-cache-miss, or a test command that expects a directory the restore was supposed to create.

Your own concurrency earned the 429

A wide matrix, several workflows triggered by one push, or a monorepo running twelve jobs that each save a large cache will produce a burst of cache traffic in a short window. The service answers that with a throttle. It is transient, and it is also a design signal: the same caches are being written many times over.

The caches are large enough to make every operation fragile

A multi-gigabyte cache takes a long time to upload and download, which widens the window in which something can go wrong, and it pushes other entries out under the eviction policy. In our experience the repositories that see cache-service errors most often are the ones caching a built tree rather than a package store.

How to fix it

Let a cache miss be a cache miss

1. Remove fail-on-cache-miss unless the job genuinely cannot run without the cache.
2. Make sure the install step runs whether or not the restore succeeded, rather than being skipped on a cache hit.
3. Re-run the workflow once the service recovers, and expect the first run after the incident to be slow.

```.github/workflows/ci.yml
- uses: actions/cache@v6
id: cache
with:
path: ~/.npm
key: npm-${{ hashFiles('package-lock.json') }}
- run: npm ci --no-audit --no-fund
Put the tolerance where the failure is If something downstream really does need the cache, guard that step rather than making the whole job depend on a service you do not control. A conditional fallback is a few lines and it turns an outage into a slow build. - uses: actions/cache@v6
id: deps
with:
path: ~/.cache/pip
key: pip-${{ hashFiles('requirements.txt') }}
- if: steps.deps.outputs.cache-hit != 'true'
run: pip install -r requirements.txt
Reduce the cache traffic you generate Cap matrix parallelism, share one warm cache across legs with restore-keys, and cache the package store instead of the...

Powered by Readybot.io