All Systems Operational

About This Site

npm loves you. Here is some info about how well it's doing.

Registry Reads ? Operational
Website Reads ? Operational
US East (NYC) Operational
US East (ASH) Operational
US East (IAD) Operational
US East (ATL) Operational
US Central (DAL) Operational
US Central (CHI) Operational
US West (LAX) Operational
US West (SJC) Operational
Europe (FRA) Operational
Europe (AMS) Operational
Europe (LON) Operational
Asia/Pacific (AU) Operational
Asia/Pacific (TYO) Operational
Asia/Pacific (NZ) Operational
Asia/Pacific (SIN) Operational
ec2-us-east-1 Operational
ec2-us-west-2 Operational
Operational
Degraded Performance
Partial Outage
Major Outage
System Metrics Month Week Day
Registry Uptime
Fetching
Registry Response Time
Fetching
Website Uptime
Fetching
Website Response Time
Fetching
Past Incidents
Aug 24, 2016

No incidents reported today.

Aug 23, 2016
For a few minutes today the package "fs" was unpublished from the registry in response to a user report that it was spam. It has been restored. This was a human error on my (@seldo's) part; I failed to properly follow our written internal process for checking if an unpublish is safe. My apologies to the users and builds we disrupted.

More detail: the "fs" package is a non-functional package. It simply logs the word "I am fs" and exits. There is no reason it should be included in any modules. However, something like 1000 packages *do* mistakenly depend on "fs", probably because they were trying to use a built-in node module called "fs". Given this, we should have deprecated the module instead of unpublishing it, and this is what our existing process says we should do.

If any of your modules are depending on "fs", you can safely remove it from your dependencies, and you should. But if you don't, things will continue to work indefinitely.
Aug 23, 20:34 UTC
Aug 22, 2016

No incidents reported.

Aug 21, 2016

No incidents reported.

Aug 20, 2016

No incidents reported.

Aug 19, 2016
At 7:55 UTC our monitoring alerted us to increased 502 and 503 rates for the website. We've determined the culprit to be a stuck Node.js process and restarted it at 8:12 UTC, which fixed the issue immediately. We will continue investigating the root cause of this problem.
Aug 19, 10:20 UTC
Aug 18, 2016

No incidents reported.

Aug 17, 2016

No incidents reported.

Aug 16, 2016

No incidents reported.

Aug 15, 2016
Starting at 22:06 UTC our monitoring started reporting increased 503 and timeout rate originating from the website. We detected what we think was an accidental mis-use of an endpoint that was creating extraordinary load. We have blocked the IP responsible and are contacting the user involved. This was resolved at 23:15 UTC.
Aug 15, 22:52 UTC
Aug 14, 2016

No incidents reported.

Aug 13, 2016

No incidents reported.

Aug 12, 2016

No incidents reported.

Aug 11, 2016

No incidents reported.

Aug 10, 2016

No incidents reported.