One in ten popular npm releases needed a hotfix. A cooldown won't skip it.

The fix usually lands within hours

Half of the 59 fixes were out within 5.7 hours of the release they fixed, and 45 within a day. Only one took longer than two days.

• @nestjs/core@12.0.0 → 12.0.1 after 24 minutes
• vue@3.5.36 → 3.5.37 after 1.3 hours
• react-router@8.0.0 → 8.0.1 after 24 hours
• @supabase/supabase-js@2.110.3 → 2.110.4 after 18.8 hours

Six of the fixes needed a fix of their own. @supabase/supabase-js went from 2.110.3 to 2.110.7 in three days.

It depends on the project, not on how often it ships

openai published 61 versions in the window and none needed a quick follow-up. @supabase/supabase-js published 36 and 10 did. 12 of the 25 packages had no hotfixes at all.

No hotfixes: react, typescript, eslint, tailwindcss, prisma, @prisma/client, nuxt, @angular/core, @playwright/test, cypress, stripe, openai.

Patch releases broke more often than minor ones

Patch (x.y.Z)

11.3%

43 of 380 hotfixed

Minor (x.Y.0)

6.3%

14 of 224 hotfixed

A patch is supposed to be the safe upgrade, yet 11.3% of patches got a quick follow-up against 6.3% of minor releases. Fix-of-a-fix chains are not the reason: without them, patches still come out at 11.5%. There were only 9 major releases, too few to compare (2 were hotfixed).

Why a cooldown doesn’t skip them

pnpm now waits a day before it installs a new version (minimumReleaseAge, default 1440 minutes), npm has min-release-age, and since July 2026 Dependabot waits three days before it opens a version-update pull request. These delays work against malicious releases because those usually get pulled from the registry within hours. When the delay ends, the bad version is gone.

Broken releases stay. None of the 59 was deprecated or unpublished. Take a release that got its fix six hours later. With a one-day cooldown, the broken version becomes installable after 24 hours and the fix after 30. For those six hours the cooldown hands you the broken version, just as the registry did on release day.

What turns the delay into a skip is hindsight. When the cooldown ends, the fix usually exists already, so a rule like “skip a version if a patch on the same line followed it faster than the project’s usual rhythm” can act on it. Combined with a one-day cooldown, that rule would have avoided 45 of the 59 broken releases; combined with Dependabot’s three days, all 59.

That rule is part of every Changes.Watch upgrade verdict: a hotfixed version gets skip and names the version to install instead.

Waiting forever isn’t safe either

152 of the 630 releases (24%) now have security advisories that a newer version fixes, across 8 of the packages. A cooldown is a delay before upgrading, not a reason to stop.

How we counted

• Packages: the 25 npm packages Changes.Watch tracks in depth, chosen for popularity, not at random.
• Releases: stable versions published 2026-04-29 – 2026-10-28, with publish times from the npm registry and deps.dev. The hotfix rate uses the 613 releases that were older than 73 hours on 2026-10-29.
• Hotfix: a newer patch on the same major.minor line published within half of the package’s median gap between recent stable releases, clamped to 12–72 hours. Each release is judged with the data available 73 hours after it shipped, so a project that patches daily isn’t counted as hotfixing every release.
• Limits: a fast follow-up is a strong hint, not proof. fastify 5.12.3 came 42 seconds after 5.12.2, which looks like a publishing slip rather than a bug report. Verdict pages always name the follow-up version so you can read its notes.
• Data: every release with its signals and verdicts, JSON, CC BY 4.0.