Is npm Down? Check Installs, Publishing and the Registry

An npm command can fail without the npm registry being down. It might be contacting a private registry, running a package script, checking security audit data or failing to authenticate. Start with the first meaningful error and the hostname it names.

Open the official npm Status page. Check installation, publishing, search or security audit as appropriate. This page is a diagnostic guide, not a live availability report. The current incident details and your command output are the evidence to compare.

Is the command reaching the registry I expect?

Inspect your active registry setting locally:

npm config get registry

Also review project and scoped registry configuration without copying tokens into logs or public messages. A package scope may use a different registry from the default. The failed request in the log is more specific evidence than the name of the command you ran.

If the destination is GitHub Packages or a GitLab registry, check the corresponding GitHub or GitLab guide. Do not replace organization registry settings with a public endpoint just to see whether an install succeeds.

Is it just this package, project or machine?

Compare the exact package and version with another authorized environment. A teammate successfully installing a different public package does not prove that your private dependency or tarball is available.

Ask whether the failure occurs in an existing checkout, a clean CI job or both. Those environments have different cached data and installed dependencies. Keep the package manager version and relevant error in your note so comparisons are meaningful.

If failures appear only behind a company proxy or on one machine, inspect that environment before assuming a public outage. A permitted network comparison can help. Do not delete the cache or lockfile before collecting evidence; both can be useful for continuing work.

Which npm component matches the failure?

The official status page distinguishes package installation, publishing, search and security audit, among other services. Check the component that corresponds to the failed operation.

Read the first failure before the final command summary. A later lifecycle-script error may have little to do with registry availability. Repeating the entire install often gives you the same ambiguity with more noise.

Does an audit error mean packages are unavailable?

Not necessarily. Establish whether dependencies were downloaded and whether the error came from the audit request. The command's overall exit behavior is not enough to identify which operation failed.

Keep the distinction in your team report. “Audit unavailable; dependency installation completed” is different from “cannot retrieve a required package.” Do not claim a clean security result when the audit did not run successfully.

If your release requires an audit result, record that check as pending and follow your normal policy. A missing audit service is not evidence that dependencies are safe or unsafe. It means the intended verification is incomplete.

Can a working cache hide an outage?

Yes, an environment with existing package data can behave differently from a clean one. That makes a successful local install useful but incomplete evidence about the registry's current reachability.

npm's configuration documentation distinguishes --offline from --prefer-offline. Offline mode prevents npm from making network requests during installation; prefer-offline can still request missing data. Neither option manufactures a package that is absent from the cache.

Do not use a cached success to dismiss a clean CI failure. Compare which package data each environment needs. Also inspect package scripts, which may involve their own tools and network requests beyond registry resolution.

What if publishing timed out?

Keep the intended package name, version and error. When access allows, inspect the registry to determine whether that version exists and whether it is the expected artifact. A lost response does not conclusively say the upload failed.

Authentication and access errors need separate checks from transport failures. Verify the intended account and package permissions without revealing credentials. Avoid changing tokens, version numbers and registry settings together.

If a release is in progress, have one person own its state. Multiple people trying to “finish the publish” can create conflicting decisions about tags or versions even when only one registry operation was originally interrupted.

How should I interpret partial outages and public reports?

A partial outage can affect one operation or some requests while other package activity works. Read the incident notes for its boundary. Search being unavailable does not establish that installation is broken, and installation recovery does not settle an interrupted publication.

Downdetector and social reports can corroborate similar errors, but they do not establish the failing registry or root cause. Check timestamps and actual hostnames. If official status is green despite your errors, read the status-page explanation.

Once the likely dependency failure is clear, follow the npm outage playbook. Preserve caches and lockfiles, work from existing dependencies and verify unfinished releases before retrying them.