Is npm Down?

No — npm is up

Reachable from all 8 checked regions

Average response time: 126ms

Last checked 2 hours ago · checks run every 6 hours

Official status page: https://status.npmjs.org

npm uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

188ms

Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 13 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

13-day clean streak

Jul 25 Today

No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams

142ms

DNS 0ms TCP 2ms TLS 8ms TTFB 23ms

lax

126ms

DNS 1ms TCP 1ms TLS 9ms TTFB 26ms

lhr

139ms

DNS 1ms TCP 2ms TLS 9ms TTFB 28ms

nrt

113ms

DNS 0ms TCP 1ms TLS 7ms TTFB 18ms

ord

173ms

DNS 0ms TCP 2ms TLS 11ms TTFB 28ms

sin

99ms

DNS 1ms TCP 1ms TLS 7ms TTFB 20ms

sjc

134ms

DNS 1ms TCP 1ms TLS 7ms TTFB 21ms

syd

94ms

DNS 0ms TCP 1ms TLS 6ms TTFB 18ms

yyz

114ms

DNS 0ms TCP 1ms TLS 8ms TTFB 36ms

What npm does

npm is the default package registry for JavaScript and Node.js. Running npm install, yarn or pnpm pulls tarballs and metadata from registry.npmjs.org, while npmjs.com hosts search and the package pages. Almost every JavaScript build depends on it, so a registry fault stops installs and pipelines across projects that share no other infrastructure at all.

What an outage looks like

npm reports the website, installs, publishes, search, Security Audit and the replication feed as separate components, so installs can fail while the site itself loads fine. Builds stop with E404, ETARGET or ECONNRESET against registry.npmjs.org, npm publish hangs partway, and npm audit times out. Continuous integration fails before local machines do, because it installs from scratch rather than from a warm cache.

What to do about it

Check status.npmjs.org, which reports installs separately from the website. If installs are the problem, npm install --prefer-offline serves anything already in the local cache, and a committed lockfile plus a restored cache in CI avoids most registry round trips. A publish that failed partway can usually be retried once service returns, though a version number that was already accepted cannot be reused.

Is it down for everyone, or just you?

If this page says npm is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

npm outage FAQ

Is npm down or is it my network?

Check status.npmjs.org, then try fetching a package directly over HTTPS. Corporate proxies, VPNs and registry mirrors sit between you and registry.npmjs.org and produce failures that look identical to an outage. If the status page reports installs healthy and a direct fetch works from another network, the problem is local, and a private registry or proxy in your configuration is the usual cause.

Can I keep building while npm is down?

Often yes. Anything already in the local npm cache can be installed without the registry, and npm install --prefer-offline will use it. A lockfile pins exact versions so nothing needs resolving against the registry, and CI systems that persist the cache between runs can survive a short outage entirely. Fresh installs of packages you have never fetched before are the ones that will fail.

Does an npm outage affect packages already deployed?

No. Installed dependencies live in your node_modules directory or inside your built artifact, so running applications are unaffected. The damage is to anything that installs at build time: continuous integration, container image builds, and fresh developer setups. This is why an npm incident often shows up as a wall of red pipelines rather than as user-facing downtime in the product itself.

Is a failed npm publish safe to retry?

Usually. If the publish did not complete, retrying once the registry recovers is the normal path. What you cannot do is republish the same version number if it was accepted, since npm treats published versions as immutable. Check the package page or the registry metadata to see whether your version actually landed before deciding between a retry and a version bump.

How we measure this

We request npm's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
Response times average only the regions that actually served the page, so a timeout never inflates the number.
Where npm publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when npm goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring

Free plan available No credit card required