Package registries
Is npm down?
Live npm status, measured independently. We probe 5 npm endpoints from monitoring regions on every continent and record every outage we detect.
npm is up
Our probes are reaching npm normally from every region we check from.
Checked every minute from 6 regions on every continent.
- Uptime, 24 hoursUptime, last 24 hours
- Uptime, 7 daysUptime, last 7 days
- Uptime, 30 daysUptime, last 30 days
- Registry ping100% uptime, 30 days6 regions, 59 to 321 msUnknownp50median response190 msp95slowest 5% of checks232 ms500 ms250024 h ago12 h agonow
- Package metadata100% uptime, 30 days6 regions, 21 to 37 msUnknownp50median response27 msp95slowest 5% of checks228 ms50 ms25024 h ago12 h agonow
- Package installation100% uptime, 30 days6 regions, 22 to 48 msUnknownp50median response30 msp95slowest 5% of checks57 ms100 ms50024 h ago12 h agonow
- Package search99.99% uptime, 30 days6 regions, 25 to 41 msUnknownp50median response32 msp95slowest 5% of checks790 ms50 ms25024 h ago12 h agonow
- Official status feed83.33% uptime, 30 days6 regions, 132 to 459 msUnknownp50median response252 msp95slowest 5% of checks559 ms500 ms250024 h ago12 h agonow
Daily strip:99.9% or better95–99.9%below 95%no data yet
Get notified when npm goes down
Follow these 5 checks from your own workspace and get alerted through Slack, email, webhooks, or on-call the moment npm goes down. They don't count against your monitor quota. Free plan, no card required.
About npm outages
The npm registry serves the packages behind nearly every JavaScript and TypeScript build. When it is slow or down, CI pipelines fail on install, Docker builds break, and deploys stall across the industry within minutes.
The npmjs.com website sits behind bot protection that rejects automated probes, so we do not measure it. We probe the registry's ping endpoint, a package metadata lookup, a real tarball download, and the search API, the calls every install and lookup makes, plus npm's status feed.
What we check
Every row is a real monitor in upti.my, running from each of our regions. A failure in some regions marks the row degraded; failures from every region mark it down and open an outage.
| Check | Target | Expects | Interval |
|---|---|---|---|
Registry ping The package registry is failing. Installs and CI builds that fetch from npm break. | httpregistry.npmjs.org/-/ping | HTTP 200 | 1 min |
Package metadata Package metadata lookups are failing. The registry may be up while resolution is broken. | httpregistry.npmjs.org/react/latest | HTTP 200 | 1 min |
Package installation Tarball downloads are failing. Installs break even if metadata resolves. | httpregistry.npmjs.org/is-odd/-/is-odd-3.0.1.tgz | HTTP 200 | 1 min |
Package search The registry search API is failing. npm search and website search break. | httpregistry.npmjs.org/-/v1/search | HTTP 200 | 2 min |
Official status feed npm's status page is unreachable. | httpstatus.npmjs.org/api/v2/status.json | HTTP 200 | 5 min |
For component-level detail and incident write-ups from the vendor, see npm's official status page.
Recent npm outages we detected
An outage is recorded when a probe fails from every monitoring region and closed when it recovers. Partial and single-region problems show as degraded above but are not listed here.
npm is up. Is your npm integration?
The incidents that actually hurt are usually not global outages. They are the parts of your own system that depend on npm and fail quietly. Here is what teams that rely on npm monitor on their side.
CI pipelines that install from npm
A failed install looks like a broken build. Monitor your pipeline's outcome with a heartbeat so a registry incident is distinguishable from a real regression.
Heartbeats for CI and cronYour own registry mirror or proxy
If you run Verdaccio, Artifactory, or a Nexus proxy, monitor it as a first-class dependency.
HTTP monitoringnpm status: frequently asked questions
Possibly. Check our registry probe first; if it is green from every region, the problem is more likely your network, a corporate proxy, or a specific package's CDN edge. Registry-wide incidents show as failures from all regions at once.
Look at the per-region results above. If our probes fail from every region, npm has a real outage and it will appear in the outage list. If they succeed everywhere, the problem is most likely on your side: your network, DNS resolver, a browser extension, a corporate proxy, or your own integration. If only some regions fail, npm may have a regional incident that does not affect you.
Every probe runs at least every five minutes from each monitoring region, and most run every minute. This page refreshes its data every minute. Uptime figures are calculated from all checks across all regions.
Official status is updated by people after an incident is confirmed and often lags the first failures by many minutes; our probes react within a minute or two. In the other direction, we only see public endpoints, so an internal incident may not show on our probes. Use both.
Yes. Use "Notify me about npm" above: your upti.my workspace follows these exact checks, free plan included, and every outage opens an incident there and routes alerts to Slack, email, webhooks, or on-call. Nothing is duplicated and it doesn't use your monitor quota. Better still, also monitor your own dependency on npm: the API route, webhook receiver, or scheduled job that calls it, so you learn about the failure that actually affects your users.
Related
Other package registries
upti.my is not affiliated with npm. npm and related marks are the property of their respective owners and are used here only to identify the service being measured. Results reflect the reachability of public endpoints from our monitoring regions and may differ from the vendor's own reporting.