My npm package page returns 404, but the tarball downloads

Last updated 2 November 2026

Your publish worked, but npm hasn't made the package public everywhere yet. npm serves a package's details and its file separately, and right after publishing one can be ready before the other. Until the package details answer, npm install fails with E404, so wait and check both before telling anyone it's out.

Why it happens

Installing a package takes two downloads from the registry:

The package document at registry.npmjs.org/<name>: the list of versions, and where each version's file is.
The tarball: the package file itself, a .tgz.

After a publish, npm processes the package and makes each one available. They don't always become available at the same moment. Developers report it can take a few minutes. Other developers have reported the opposite order too: the version listed, but the tarball still returning 404.

How to check it yourself

Check each part (for a scoped package, write the / in the name as %2f in the first address):

curl -s -o /dev/null -w "%{http_code}\n" "https://registry.npmjs.org/@scope%2fname"
curl -s -o /dev/null -w "%{http_code}\n" "https://registry.npmjs.org/@scope/name/-/name-1.0.0.tgz"
npm access get status @scope/name

200 on both means people can install it. 404 on the first and 200 on the second is this case. If npm access get status answers public, npm has your package; it's still on its way to being public.

What to do next

Wait, and check both addresses again every minute or so. Don't announce the release until both return 200.
Don't unpublish and publish again in a hurry. npm doesn't let you reuse a version number, so a panic republish needs a new version.
In a release script, replace any fixed wait with a loop that checks both addresses until they return 200, with a time limit.
If it's still 404 after hours, contact npm support. Developers have reported packages left in a broken state on the registry side that needed npm's help.

The proof

@golproductions/jogga 1.0.0, published 2 November 2026. In the minutes after the publish:

The package document returned 404 on every check, for at least 3 minutes, even with a unique query on each request.
The tarball returned 200, and its SHA-1 matched the publish output exactly: 31dcfb115ffb857c4350bc3a1f2f44ee7f3b54e8.
npm access get status answered public, and the package was listed in the publisher's account.
Installing it failed with E404.

Later, installing it worked, with no change on our side.

Where Flora comes in

Flora, which we make, checks both: that the version is listed and that the file npm serves matches what you packed, byte for byte. If the listing is slow, she waits up to 60 seconds inside one call. A check costs A$0.01.

NOT PUBLISHED: @golproductions/no-such-pkg-xyz isn't on npm's public list. Nobody can install it.
PUBLISHED: @golproductions/flora@1.0.0 is listed, and the file npm serves matches what you packed, byte for byte.

What this page doesn't cover

This is one case we saw, on the public npm registry. How long it lasts varies. Private registries, GitHub Packages and company mirrors work differently. Before publishing, we had also looked the name up while it didn't exist yet; we can't rule out that a cached "not found" from that lookup made the wait longer.

Questions people ask next

Can people install my package while its page returns 404?
No. npm install reads the package document first. In our case, installing failed with E404 while the tarball already downloaded.

Will it fix itself?
In our case, yes: later the package installed normally, with nothing changed on our side. If it lasts hours, contact npm support.

Should I publish a new version to fix it?
We didn't need to. Wait and check first. You can't publish the same version number twice, so a new publish means a new version.