Blog

When install is degraded and the website is not on the update

2026-10-26

On 22 October 2026 npm incident xfp75s9j3bp8 opened at 02:33 UTC with Package installation and Package publishing degraded. The website component joined at 02:37. At 09:00 the same monitoring sentence left those components degraded until 11:59.

At 02:33 UTC on 22 October 2026, the first update on npm incident xfp75s9j3bp8 named two components. Package installation moved from operational to degraded performance. Package publishing did the same. The www.npmjs.com website was not on that update. At 02:37 it was, and both registry components moved from degraded performance to partial outage. A build that failed in those four minutes was on the registry. A browser that still opened the site was not evidence against that.

What the 02:33 update named

The public incident page prints the update bodies and, at the bottom, one rolled-up line: this incident affected the www.npmjs.com website, Package installation, and Package publishing. That line hides the four minutes. The per-update component list is on the incident JSON. npm's own component text, on that same record, says Package installation is the ability to read from the registry so that users can install packages, and the website component is the ability to navigate to or interact with the npm website. Package publishing has no description on the component.

• 02:33 UTC: investigating. "We are currently investigating this issue." Package installation and Package publishing move from operational to degraded performance. The website is not in the component list.
• 02:37 UTC: still investigating. "We are continuing to investigate this issue." Installation and publishing move from degraded performance to partial outage. The website moves from operational to partial outage. This is the first update that names it.
• 03:07 UTC: identified. "The issue has been identified and a fix is being implemented." All three stay at partial outage.
• 04:10 UTC: monitoring. "A fix has been implemented and we are monitoring the results." All three move from partial outage to operational.
• 04:24 UTC: resolved. "This incident has been resolved." The three components are already operational. npm's incident record sets the impact to major. The page stamps run from 02:33 to 04:24, 1 hour 51 minutes.

UptimeRobot's note for 22 October records the same incident, the same 1 hour 51 minutes, and the same three components on the rolled-up list. It does not mention that the website was absent at 02:33. Use UptimeRobot for the clocks and the day. Use the incident JSON for which update first named the website. The HTML footer is the union, not the 02:33 sentence.

The same sentence at 09:00 did not move the component

At 06:43 UTC npm opened a second incident, 56x3sh4qhr9s, titled Degraded Publish, Install, and View Package. That is 2 hours 19 minutes after xfp75s9j3bp8 resolved. The footer again lists the website, Package installation, and Package publishing. The incident JSON marks the impact minor, not major.

• 06:43 UTC: investigating. "We are currently investigating this issue." All three components move from operational to degraded performance.
• 09:00 UTC: monitoring. The body is the same sentence as the 04:10 update: "A fix has been implemented and we are monitoring the results." On this update the three components stay at degraded performance.
• 11:59 UTC: resolved. "This incident has been resolved." All three move from degraded performance to operational.

The page stamps run from 06:43 to 11:59, which is 5 hours 16 minutes. UptimeRobot lists this second incident as 5 hours 18 minutes and notes that the gap from the 09:00 monitoring line to 11:59 is unexplained beyond that sentence. Keep both durations. Do not average them into a third number nobody printed. What the JSON adds, and UptimeRobot's summary does not, is that monitoring at 09:00 left the components where they were, while monitoring at 04:10 had already moved them to operational. The words are not the component.

Package search, Security Audit, and Replication Feed are on npm's status page and are not on either footer. A failure in one of those is not these two incident IDs.

View package, on the days the component was the website

At 05:54 UTC on 26 October npm opened hf0q2nhdk5cp, titled View package and auth outage on npmjs.com. The footer is one component: www.npmjs.com website. The incident JSON sets the impact to major. Package installation is not on it.

• 05:54 UTC: investigating. "We are currently investigating this issue." The website moves from operational to partial outage.
• 06:11 UTC: identified. "The issue has been identified and a fix is being implemented." The website moves from partial outage to degraded performance.
• 06:21 UTC: monitoring. The same fix-and-monitoring sentence. The website moves from degraded performance to operational.
• 06:30 UTC: resolved. The website is already operational.

The page stamps run from 05:54 to 06:30, 36 minutes. UptimeRobot's outage list calls it major, 36 minutes, starting 05:54 UTC. Technobezz records the same four updates in Eastern time, 1:54 a.m. to 2:30 a.m. on 26 October, and describes the scope as package viewing and authentication on the www.npmjs.com website. That matches the footer. It does not add Package installation.

Twelve days earlier, nwrj52br2kjv was the plain-language version of that title. At 09:29 UTC on 14 October the body said npm had observed increased errors and latency in login and viewing packages. At 11:06 they added increased errors accessing package settings. The footer is the website only. On the incident JSON the impact is minor, the website stays at degraded performance through the identified update at 11:20 and the monitoring update at 11:33, and it moves to operational on the resolved update at 11:44. "Viewing packages" in that sentence is the website component. It is not Package installation.

Copy you can adapt

The weak version, which could be pasted onto either morning:

npm had a rough morning but the website is up and they are monitoring a fix. Builds should be fine. If a package page fails to load, retry.

That paragraph costs the component that actually moved. At 02:34 UTC on 22 October the website was not on the update, and Package installation was already degraded, so "the website is up" does not clear a failed install. At 09:05 the monitoring sentence was on the page and the JSON still had installation, publishing, and the website at degraded performance, where they stayed until 11:59, so "builds should be fine" restarts a job the component has not cleared. At 06:00 UTC on 26 October the open incident is the website, titled view package and auth, and Package installation is not on it, so a failed install at that minute is a different ticket from a package page that will not load. One note cannot be true for all three clocks.

Three notes that name the component:

02:40 UTC, 22 October. npm incident xfp75s9j3bp8. At 02:33 UTC Package installation and Package publishing moved to degraded performance. The www.npmjs.com website was not on that update. At 02:37 the website joined at partial outage, and installation and publishing moved to partial outage. npm describes Package installation as reading the registry to install packages, and the website as navigating or interacting with npmjs.com. A failed npm install is in this incident. A browser that opened the site at 02:34 was not a counterexample. Package search, Security Audit, and Replication Feed are not on this incident.

09:10 UTC, 22 October. xfp75s9j3bp8 resolved at 04:24 UTC, after a 04:10 monitoring update that had already moved the website, installation, and publishing back to operational. That line does not cover the new incident. 56x3sh4qhr9s has been open since 06:43 UTC, impact minor on npm's incident record, with those same three components at degraded performance. The 09:00 update says a fix has been implemented and they are monitoring. On the incident JSON that update does not change the component status. Install and publish stay degraded until a later update says otherwise. The 04:24 resolved line is a different incident ID.

06:15 UTC, 26 October. npm incident hf0q2nhdk5cp, opened 05:54 UTC, impact major. The title is View package and auth outage on npmjs.com. The affected component is the www.npmjs.com website, at degraded performance since the 06:11 update. Package installation is not listed. A package page or login that fails is in this incident. An install that fails is not, until an update names that component. On 14 October, incident nwrj52br2kjv used the words login and viewing packages for a website-only incident. Same split.

A reader who was not on the bridge can check each sentence against the incident page and the incident JSON. The weak paragraph cannot be checked, so it cannot be trusted an hour later.

What not to do

• Do not read the rolled-up footer as the first update. On xfp75s9j3bp8 the website joins at 02:37, four minutes after installation and publishing.
• Do not treat "a fix has been implemented and we are monitoring the results" as a component change. At 04:10 and at 06:21 on the 26th it moved components to operational. At 09:00 on the 22nd, and at 11:33 on 14 October, it did not.
• Do not let a resolved ID cover the next ID. 04:24 closed xfp75s9j3bp8. 56x3sh4qhr9s opened at 06:43.
• Do not read "view package" or "viewing packages" as Package installation. On hf0q2nhdk5cp and nwrj52br2kjv the component is the website.
• Do not add Package search, Security Audit, or Replication Feed to these notes. They are not on the footers.

Operator checklist

1. Write the incident ID, then the component names on that update, not the title alone.
2. When a later update adds a component, keep the earlier list. The 02:33 list and the 02:37 list are both true, at different minutes.
3. On a monitoring update, read the component status before and after. The sentence is shared. The status change is not.
4. When an ID resolves, start a fresh note for the next ID. Do not extend the resolved line forward.
5. If the failing command is npm install, look for Package installation. If the failing surface is a package page or a login, look for the website component.

The public directory of hosts we probe is /status. The GitHub page at /status/github, read at 17:55 UTC on 26 October 2026, showed the service host reachable, the vendor feed operational, and no independently measured reachability incidents from 19 October 17:55 UTC through that reading. That probe is api.github.com. It is not www.npmjs.com, and it is not the registry read npm calls Package installation. We do not publish an npm truth page. Reachable means that GitHub host answered. The component for an npm install still comes from the npm incident.