npm status

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.

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.