NuGet restore 503 / 5xx - Transient Feed Errors in CI

The feed answered, but with a 5xx status - 503 Service Unavailable, 502 Bad Gateway, or 500 - meaning the feed itself is temporarily unhealthy. These are server-side transient failures, not anything wrong with your project.

What this error means

Restore fails partway through with a 5xx status from the feed, often "503 (Service Unavailable)". Re-running the job a minute later usually succeeds with no change, which distinguishes it from a 401/403 (deterministic auth) or NU1101 (deterministic resolution).

dotnet restore output

error : Response status code does not indicate success: 503 (Service Unavailable).
error : Unable to load the service index for source
https://pkgs.dev.azure.com/contoso/_packaging/internal/nuget/v3/index.json.

Common causes

Feed temporarily overloaded or in maintenance

A hosted feed under heavy load or mid-deploy returns 503/502 for a window. Azure Artifacts, GitHub Packages, and nuget.org all occasionally throttle or 5xx.

Upstream/CDN hiccup behind the feed

A feed backed by blob storage or a CDN can surface a transient upstream 5xx even when the index endpoint itself is up.

How to fix it

Add a bounded retry around restore

A short retry loop absorbs a transient 5xx without a full job re-run.

Terminal

for i in 1 2 3; do
  dotnet restore && break
  echo "restore failed (attempt $i), retrying in 15s"; sleep 15
done

Cache packages so a blip does not block

A warm global-packages cache means most packages are already local and a feed 5xx matters far less.

.github/workflows/ci.yml

- uses: actions/cache@v4
  with:
    path: ~/.nuget/packages
    key: nuget-${{ hashFiles('**/packages.lock.json') }}

How to prevent it

Retry restore on 5xx rather than failing the whole job immediately.
Cache the NuGet global packages folder keyed on the lock file.
Use an internal upstream/pull-through feed to smooth over public-feed blips.