It depends on the tool, and the numbers are not comparable. npm retries twice with waits of 10 to 60 seconds and a 5 minute request timeout. pip makes up to 5 connection attempts with a 15 second socket timeout. Cargo retries 3 times. Set a job timeout instead of trusting any of them.
The documented defaults
| Tool | Setting | Default | What it means |
|---|---|---|---|
| npm | fetch-retries | 2 | Retries idempotent reads on network failures or 5xx errors |
| npm | fetch-retry-mintimeout | 10 seconds | Shortest wait between retries |
| npm | fetch-retry-maxtimeout | 1 minute | Longest wait between retries |
| npm | fetch-retry-factor | 10 | Growth factor for the wait |
| npm | fetch-timeout | 5 minutes | Longest wait for one request to finish |
| pip | retries | 5 | Maximum attempts to establish a new HTTP connection |
| pip | timeout | 15 seconds | Socket timeout |
| cargo | net.retry | 3 | Retries for possibly spurious network errors |
These come from the npm config reference, the pip CLI reference and the cargo configuration reference. Defaults can change between versions, so confirm them for the version you run.
Why the numbers mislead
The settings measure different things. pip counts connection attempts, not whole install attempts. npm's retry applies to individual requests, and its request timeout is long enough that one stalled download can hold a job for minutes before a retry even begins. Cargo's value is a count with no wait time stated on the page.
So you cannot add them up into one tidy figure for "how long until CI gives up". A registry that answers slowly instead of failing outright is the worst case, because every request waits for its timeout.
What to do about it
- Put a timeout on the whole dependency step, for example 10 minutes. A hung install should fail with a clear message, not sit for an hour. See CI job timeouts stop runaway and hijacked jobs.
- Leave the retry counts near their defaults. Raising them in a fleet turns a short outage into a flood of repeat requests, the pattern described in retry storms.
- Add one scripted retry around the whole step with a pause, rather than ten tool level retries inside it.
- Print which registry host failed. Developers lose time when the log says only "install failed".
- Point installs at a mirror you control so the public registry is not in the path. The options are compared in vendoring vs cache vs mirror.
A note on the offline option
npm documents an offline mode that makes no network requests during install and a prefer-offline mode that skips staleness checks for cached data but still fetches what is missing. Cargo documents a net.offline setting that avoids the network and uses locally cached data. These do not replace retries. They are the next step when retries are not enough, covered in npm ci and cache during a registry outage.
Where Safeguard fits
When installs fail and you switch to a cache or mirror, you still need to know which versions went into the build. Safeguard's SBOM and dependency scanning records that inventory per build, so a fallback path does not leave a gap in your records.
Quick check
Should I raise retries to survive outages?
Usually no. Higher counts across many runners add load to a registry that is already struggling. Use a mirror and a job timeout instead.
Are these defaults the same in every version?
Not guaranteed. The values above come from the current documentation we checked. Confirm them against the tool version your runners use.
Sources
Last reviewed: 19 October 2026.
