# npm status

> Is npm down? Live status for the npm registry, uptime history, and per-region response times measured by our own probes every 2 minutes.

Published: 2026-08-19 | Canonical: https://yoping.me/status/npm

## How we check npm

We watch registry.npmjs.org from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the registry host that every npm install actually talks to, not the website where humans browse packages. The two are separate systems and the website being reachable tells you nothing useful about whether an install will resolve, which is the failure that stops builds.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/npm. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## What is npm?

npm is the package registry behind the JavaScript ecosystem, and the
scale of what depends on it is easy to underestimate. A single modest
application can pull in hundreds of packages, each with dependencies of
its own, and every one of those is fetched from the registry the first
time a project is installed. The result is that npm sits underneath a
very large share of the software being built at any given moment, in a
position where a short outage is felt by an enormous number of people
who have no direct relationship with it at all.

The failure mode is specific and worth being precise about, because it
regularly causes an unnecessary panic. An npm outage does not take
production down. Code that is already installed keeps running: the
dependencies live in node_modules or baked into a container image, and
nothing at runtime reaches out to the registry to check that they are
still there. What breaks is the ability to build. CI pipelines fail at
the install step, container builds fail on the same line, a developer
joining the project cannot get it running, and any deploy that installs
dependencies as part of its process stops partway. The service you are
running is fine. The ability to ship a change to it is gone, which is a
different emergency with a different response.

The second thing that makes npm incidents confusing is how unevenly they
land. Installs that resolve from a local or CI cache succeed without ever
contacting the registry, so during a partial outage some builds fail and
others sail through, on the same commit, minutes apart. That randomness
tends to send people looking for a flaky test or a race condition in
their own pipeline. It is also why a registry problem often gets reported
as "CI is being weird today" for a while before anyone connects it to
npm.

Publishing is worth separating from installing. They are different
operations against different parts of the system, and it is normal for
one to be degraded while the other works. A release pipeline that fails
at the publish step while installs across the company continue normally
is a real pattern, not a contradiction.

There is also a broader lesson in npm's incident history that applies
well beyond JavaScript. A registry is a single point of failure that
almost nobody treats as one. Most teams have no fallback for it, no
mirror, and no documented answer to the question of what to do when it is
unavailable, largely because it is reliable enough that the question
never comes up. Knowing quickly that the registry is the problem, rather
than your pipeline, is most of what you can usefully do in the moment.

## Frequently asked questions

### Is npm down right now?

Check the board above; it reflects our own probes against registry.npmjs.org from all five of our regions, refreshed every couple of minutes. That is the host your package manager talks to, so it is the reading that matters for a failing install.

### My npm install is failing. How do I tell whether it is npm or me?

Look at what the error actually says before assuming an outage. ETIMEDOUT or ECONNRESET against registry.npmjs.org points at the network path or the registry; a 404 on a specific package points at a name, a version, or a private package your token cannot see; and EINTEGRITY points at a corrupted local cache, which npm cache clean --force resolves. If the board above shows the registry answering normally from several countries, the cause is much more likely to be one of the last two.

### Does an npm outage break production or only builds?

Only builds, in almost every case. Installed dependencies live in your node_modules directory or your container image and keep running regardless of whether the registry is reachable. What stops is anything that installs afresh, meaning CI pipelines, container builds, a new developer setting up the project, and deploys that run an install step. A running service does not care that npm is down until the next time it is rebuilt.

### Why does npm work for me but fail in CI?

Because CI usually installs from scratch while your machine installs from a warm cache. A local install that resolves entirely from the npm cache can succeed during a registry outage without touching the network at all, which makes the failure look like a CI-specific problem when it is a registry problem your cache happened to hide. Corporate proxies and private registry mirrors, which CI often routes through and laptops often do not, produce the same asymmetry.

### Should I be running a registry mirror or a lockfile-only install?

A lockfile plus a cache gets you most of the resilience for none of the work, and it is where to start. Committing a lockfile and using npm ci means builds resolve exact versions rather than searching the registry for a satisfying range, and a warm cache in CI can carry you through a short outage without noticing. A private proxy registry goes further and is worth it for larger teams, but it is infrastructure of its own, with its own outages to watch.