What to Do When npm Is Down

If npm requests are failing, keep your installed dependencies, cache and lockfile intact. Deleting them can turn a project that still builds locally into one that cannot start until the registry recovers.

Check the official npm Status page for installation, publishing or audit incidents. If you have not confirmed which service the command is contacting, start with Is npm down?. A failing npm command can involve a private registry or a package script rather than npm's public service.

Stop reinstalling and capture the actual failure

Save the first meaningful error, hostname, package version and time. Keep the command you ran and the package manager version. Do not publish complete configuration files or logs containing registry tokens.

Pause repeated clean CI attempts if they all fail at the same download. Identify whether any job is still publishing or deploying before cancelling or rerunning it. Keep one owner for an interrupted release.

Avoid deleting the lockfile or changing package versions to make an outage disappear. Those changes alter dependency resolution and can produce a different build. If you genuinely need a dependency change, review it as a code change with its own reason and checks.

Confirm the scope and tell the team

Inspect the failing registry address and compare one affected package in another authorized environment. An existing cache can explain why one machine works while a clean runner fails, so include that difference in your note.

Use a team update like this:

npm [installation/publishing/audit] is affecting [project or release]. Requests to [hostname] fail with [error] at [time and timezone]. The official incident is [link], or confirmation is pending. Preserve existing dependencies and avoid repeated clean installs. [Owner] will update at [time].

Downdetector and social posts can support a suspected wider problem, but do not identify your registry or package failure on their own. If the destination is another vendor's registry, use the GitHub or GitLab playbook as appropriate.

Work with the dependencies you already have

Keep using a working checkout for local code changes, tests and documentation. Avoid unnecessary dependency additions while access is unreliable. A code review, failing test or small refactor can often proceed without a new install.

Be careful with commands that recreate the dependency directory. npm documents that npm ci removes an existing node_modules before installing. Do not use a clean install as your first connectivity probe in the only workspace that still works.

If you already have an approved internal cache or artifact source, use its established procedure. Do not switch to an unfamiliar mirror during an outage, especially for private packages. Preserve the lockfile and normal integrity checks rather than accepting a different dependency graph for convenience.

Know what offline installation can and cannot do

npm's configuration reference explains that --offline prevents npm's installation network requests, while --prefer-offline still fetches missing data. A cache must contain the needed material for an offline install to succeed.

If you need to test that path, use a disposable checkout that does not contain your only working dependency directory. Keep the existing lockfile and record which command you used. An offline failure is not a reason to erase the cache.

Package lifecycle scripts can run additional tools, so assess the project before treating an offline package-manager option as proof that the whole build has no network dependencies. Keep incomplete checks clearly marked in your development notes.

Separate installation, audit and publishing

If the failure is audit-only, determine whether dependency installation completed. Record the security check as pending. If your policy allows continuing local development without that result, do so while keeping the release requirement visible. Do not present an unavailable audit as a successful audit.

If installation is failing, identify the specific missing metadata or package download. Do not rebuild the entire environment repeatedly when the same required artifact remains unavailable. Use existing working dependencies for tasks that permit it.

If publishing is interrupted, preserve the intended version, tag and artifact. Verify the registry state before another attempt. A timeout can mean the response was lost after the operation succeeded. Avoid changing the version number simply to get around an uncertain result.

Recover without a rush of duplicate releases

Read the provider update, then check your own affected operation. The shared status-page guide explains why a healthy headline does not settle every component or pending task.

1. Test retrieval of a representative required package and version.
2. Run the normal reproducible install in a suitable clean environment.
3. Complete any audit or other verification that was unavailable.
4. Inspect interrupted package publications and release tags before retrying.
5. Resume paused CI work gradually, checking downstream deployment effects.
6. Confirm the lockfile and registry configuration have not drifted during troubleshooting.
7. Tell the team which builds and releases are verified.

Record whether the useful workaround was an existing cache, a working checkout or simply choosing work without new dependencies. That is better evidence for future improvements than assuming every project needs a new registry service.

An optional break while the registry recovers

Once the release state is owned and useful work is covered, join the Nines ping list. Nines is a tiny browser arcade that opens during qualifying official developer-tool outages. Degraded banners alone do not open it.