NPM's package publishing and private install systems broke for 6 hours and 1 minute on 27 September 2026, starting at 00:50 UTC. This was a fault on npm's side, not something fixable from your end.
Started
00:50 UTC
Duration
Lasted 6h 1m
Source
IsDown
Next time
npm is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Package installation, Package publishing
What happened?
npm's own status page recorded a single incident on this day, titled "Issues with npm package publish and private install". It started at 00:50 UTC and was marked resolved at 06:47 UTC, giving a total duration of 6 hours and 1 minute. Two components were listed as affected: package installation and package publishing. npm posted three updates across the window. The first, at 00:50, said they were investigating. The second, at 01:30, said a fix had been implemented and they were monitoring the results. The third, at 06:47, simply said the incident had been resolved. There is no detail in between explaining what the fix was or why it took over five more hours to confirm it worked, so the cause is not on the record. No user reports were filed during this window on our side, which is unsurprising given that publish and private install issues tend to surface for CI pipelines and package maintainers rather than ordinary end users. Over the past 90 days npm has logged 8 incidents with a median duration of 2 hours and 1 minute, so this one ran roughly three times longer than typical. Across npm's full history, 188 incidents have been recorded at a rate of 2.5 per month.
Learning
Our own probes watched the npm registry from both EU and NA regions through this period and recorded 100% uptime for the day, the week and the month, and this incident was not flagged against our monitoring. That is not a contradiction. Our checks poll the registry's basic availability every 60 seconds, which tells you the registry was reachable and responding, but publish and private install are specific write and authentication paths that can fail while the registry itself stays up and answers simple requests. This is the shape of failure to watch for in your own product: a backend can look perfectly healthy on a surface check while a particular operation, like pushing a new package version or pulling from a private scope, is silently broken. If your CI jobs or deploy pipelines depend on npm publish or private installs, an uptime check against the registry root would not have caught this, and you would have seen failures with no obvious external explanation. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
