Is npm unavailable, or is a package command failing only on your machine? Check npm’s current service status, distinguish a registry incident from a local or network problem, and choose the next diagnostic step for installs, publishing, login, or website access.
Site Administrator
Last reviewed: September 25, 2026
LATEST RECORDED STATUS
Up npm’s website appeared to be up and responding normally at the last check.
| Endpoint | Status | Observed |
|---|---|---|
| npmjs.com | Operational | 2026-11-09 14:55 UTC |
| registry.npmjs.org | Operational | 2026-11-09 14:55 UTC |
Is it working for you?
0 recent reports — more reports are needed for a useful trend.
For the full picture, including partial or regional outages a single external check may miss, see npm’s official status page. official status page.
npmjs.com and requests to registry.npmjs.org as separate checks.
npm has several access paths that can fail independently. The npm website uses npmjs.com, while package installation, dependency resolution, and publishing commonly involve registry.npmjs.org. The website may load while registry requests fail, or a registry incident may affect package commands without making the website appear completely offline.
For the broadest service-level view, check npm’s official status page. Match any incident to the operation that is failing—such as package retrieval, authentication, publishing, registry/API access, or website access—instead of assuming that every npm function is affected.
A status page can confirm a reported platform issue, but it cannot diagnose a project-specific failure. The exact npm error, configured registry, affected package, and whether the same request works from another network are often more useful for separating an npm incident from a local, account, or connectivity problem.
Open the official npm status page and look for an active or recently resolved incident affecting the registry, package downloads, authentication, publishing, or the website. If the reported issue matches your failing operation, avoid disruptive project changes and retry after the incident is resolved. If no matching incident appears, a regional, network, account, or project-specific problem is still possible.
If installs or package resolution fail across multiple projects, prioritize registry access, DNS, proxy, firewall, and npm configuration checks. If only one project or package fails, inspect its dependency declaration, lockfile, package name, version, and configured registry before treating the problem as an npm outage.
Publishing and login failures require separate analysis from public package downloads. Review the complete error, the account or token being used, the target registry, and whether the failure affects one package, organization, or account operation.
NXDOMAIN: the resolver cannot find the requested host. Compare DNS behavior on another network and check VPN, filtering, and local resolver settings.Check the configured registry and proxy settings, especially after switching networks, enabling a VPN, or using a private registry. For login, publishing, or private-package access, verify that the intended account has the required permission and that credentials or tokens have not expired. Never expose tokens in terminal output, issue reports, or support requests.
If the npm website fails in a browser while package commands still work, try a private window or another browser and temporarily disable extensions that block scripts or cookies. If both the browser and npm commands fail, prioritize the status page and network checks rather than browser-only fixes.
When registry.npmjs.org is unreachable while the website works, assess the registry path separately and record the exact HTTP status or npm error. A 5xx response can indicate a server-side or upstream problem; a 4xx response more often points to an invalid request, missing permission, authentication issue, rate limit, or unavailable package. Preserve the package name, command, time, and complete error when escalating, but remove credentials and tokens.
Use the status page alongside the exact npm error and local connectivity checks. A clear status page does not exclude a regional, account-specific, DNS, proxy, or project-level problem.
Every time this page loads, our server makes its own request to npmjs.com (and its API domain, when applicable) and reports what it got back — a real HTTP response, a timeout, or a connection failure. That result is cached for up to 2 minutes.
This confirms external reachability; it does not test every feature, region, account, or network path. Cross-check the official status page when one is available.
No. This is a live, one-off connectivity check run from our own server, not npm's own incident reporting. Their official status page can show partial, regional, or component-level issues our single external check cannot detect.
A basic reachability check confirms that the server responded to our request. It does not test every feature, region, ISP, browser, or account-specific issue.
A check is refreshed after the two-minute cache expires. The displayed check time shows when the observation was made.
Not necessarily. Many services split their website and API onto separate infrastructure, so one can fail while the other keeps working.
Check the official npm status page for current incidents. If there is no matching incident, compare access to npmjs.com with requests to registry.npmjs.org and investigate local network, DNS, proxy, configuration, or account causes.
npm install still fails?The website and package registry are separate access paths. Your browser may reach npmjs.com while registry requests are blocked by DNS, a firewall, proxy, VPN, TLS inspection, or an npm registry setting.
Publishing requires authentication and package permissions that differ from downloading a public package. Review the exact authentication or permission error, confirm the intended registry, and check whether npm reports an incident affecting publishing.
The failing network may use a different DNS resolver, proxy, firewall, VPN, or TLS inspection policy. Compare the same operation on a trusted alternate connection and review the configured registry and proxy settings.
node_modules or the lockfile when npm is unavailable?Not as a first step. If the registry or network is unavailable, deleting local dependency files will not restore access and can make reproduction harder. Check service status, the exact error, npm configuration, and connectivity first.
Record the command, affected package or operation, exact error text, approximate time, configured registry, and whether the failure occurs across projects or networks. Remove authentication tokens and other sensitive values before sharing logs.
This is a live connectivity check from our server, not an official statement from npm. A down result may also reflect a regional or partial outage.