npm ERR! 429 Too Many Requests

[wwoofisrael]

hi We have 30-40 microservices that run npm install concurrently, and we get this error, npm ERR! 429 Too Many Requests

[nprail]

We are experiencing the same problem. NPM is logged in.

$ npm ci
npm ERR! code E429
npm ERR! 429 Too Many Requests: optipng-bin@3.1.4

npm ERR! A complete log of this run can be found in:
npm ERR!     /builds/conva-apps/chap-mobile/.npm-cache/_logs/2018-05-28T21_54_51_355Z-debug.log
ERROR: Job failed: exit code 1

This issue is breaking every single build that uses NPM.

[joaomoreno]

We (VS Code) have also started getting lots of these in our builds.

Would authentication work in raising the limits, here? I'm finding it very hard to find out information about that and about how to set that up at all.

[nprail]

The issue seems to have stopped for us.

@joaomoreno We were always logged in but that didn't help when it wasn't working.

[nathanburrell]

Us aswell (Bitbucket Pipelines) ran into this the other day.

I found this blog entry describing (albeit vaguely) that non logged in vs logged in users have different rate limits, and also this issue to improve the docs about rate limiting.

As it is working again now but its vague as to why it failed, it would be good to know what are the current rate limits that are applied (to logged in vs anonymous users) and also for anonymous users how do you collate them (based on IP?).

[IanSavchenko]

We started to observe the same behavior on our builds with Travis CI 2 days ago. The issue still pops up randomly.

[DrRataplan]

We are having this issue at this moment, currently on 5 consecutively failed builds. We use bitbucket pipelines and we are not logged in. It seems that the build I've just started is going to work though.

Is this rate limiting based on IP?

[sg3s]

We encountered this issue as well on Bitbucket Pipelines. And since finding this issue ~40 minutes ago @nathanburrell 's comment gained ~8 thumbs up so I'm guessing it's quite wide spread now.

I can imagine that quite a lot of installs from Bitbucket Pipelines are done from a limited IP range, so that might cause it, though it is hard to judge as documentation is sparse at best.

[inakrin]

Experiencing the same in the bitbucket pipelines

[nathanburrell]

If it is IP based (as I suspect it may be for anonymous users), these are the IP ranges we use on Bitbucket Pipelines, if we could get a different rate limit associated with those that would be great :) (assuming it is IP based)

At the moment if you are using pipelines, I would suggest using our dependency caching feature as that will decrease the number of calls you make to NPM (whilst also speeding up your builds), atleast until NPM replies and we can sort something out :)

[j4m355]

@nathanburrell - any chance of an update on the status page to indicate that there is a problem being looked into? It's affecting all our pipelines builds this morning and using up our build minutes.

[dlhines]

Anonymous user and it has failed 8 times in the past 20 mins...why I found this...

[alextiley]

Same issue here. Running npm install via bitbucket pipelines results in the rate limit error (HTTP 429). We're using dependency caching and have been for 3 months+

Is there anything we can do from our end or is just a case of waiting for somebody to 'fix' it?

[brianvandelden]

Same here. Tried as loggedin npm user as well, but same error on Bitbucket pipelines

[nathanburrell]

@j4m355 its not an issue with pipelines, but with NPM as its NPM thats rate limiting us.

Ill look into our policies around our status page, as we generally only update that when its an issue with our services or one of our direct dependencies (we dont directly depend on NPM, but I guess our users do but for their builds)

[felamaslen]

Yup I'm getting E429 on BitBucket builds in various places.

[antogyn]

Same problem on Bitbucket Pipelines

[joemewes]

Same problem on Bitbucket Pipelines as well. But see that its not pipelines specific.

[nathanburrell]

We are in the process of updating our status page, and trying to contact NPM to get this resolved.

[j4m355]

@nathanburrell agreed - not an issue with pipelines directly - but its clear a lot of people here are pipelines users and putting time into looking this up and you could save them a bit of time with some better communication - thanks for looking into the process for updating the status page - it will help others

[inakrin]

#SORRY, IT DIDN"T WORK. IT WORKED ONCE ONLY# It worked after I've logged in in the pipeline as described here : https://npme.npmjs.com/docs/tutorials/pipelines.html (And added this line from the pipeline example to my pipeline):

• printf "//node -p \"require('url').parse(process.env.NPM_REGISTRY_URL || 'https://registry.npmjs.org').host\"/:_authToken=${NPM_TOKEN}\nregistry=${NPM_REGISTRY_URL:-https://registry.npmjs.org}\n" >> ~/.npmrc

[mathiasmaenhout]

Same problem here. Using Bitbucket Pipelines as well. Is there a workaround?

[joemewes]

we're working logged in already with private packages in bitbucket pipelines and still getting 429 rate limiting. if that helps anyone. Is there a link going around to what the npm API rate limiting policy is? per hour/ per day I mean?

[nathanburrell]

@joemewes see my comment above about the rate limiting, tl;dr theres an open issue to document it as atm theres only a blog post that vaguely describes it.

[sakulstra]

our travis builds randomly fail as well - we just switched two days ago to npm ci over npm install + node_modules cache and it never happened before so this might be part of the issue?

[Nuruddinjr]

Also confirming our Bitbucket pipelines are failing because of this. Waiting for update from NPM :-)

[pjoe]

FWIW: This was working for us on Bitbucket Pipelines yesterday, but all builds today has failed with 429 errors.

[phillipsnick]

Also having issues with Bitbucket pipelines. Seems to work 1 in 5 times!

[netzon-gil]

We have the same issue. We're also using Bitbucket Pipelines.

[bergie]

There was this bit in a recent NPM incident report:

We are making some changes to the way we serve registry data. We are actively monitoring the effect of these changes.

Maybe related?

[netzon-gil]

https://status.bitbucket.org/?_ga=2.20995326.497816218.1527647425-770271235.1522817183

[nathanburrell]

Hey, quick update, we have reached out to npm, but havent heard back yet.

We will update the status once we have a reply :)

https://status.bitbucket.org/incidents/dt7bxd954z0m

[bergie]

@vitolimandibhrata logging in doesn't seem to help really. Still failing the build more often than succeeding

[volodymyrrudyi]

Same here, this is going to be a huge issue!

[kylecordes]

It's really unfortunate that this is rolled out in a way that breaks all users of BitBucket and probably some other similar services. At the same time, it really would be better if BitBucket and similar services operated a local mirror/cache of NPM, Maven, etc., rather than send all of that load upstream and trigger rate limits.

[mAiNiNfEcTiOn]

@kylecordes indeed it would, but also it would be far more efficient if companies would set it up when there's none. Both cases are not happening so we end up with hitting the rate limit :)

[kylecordes]

Really the situation is frustrating all around:

• As customers of BitBucket, we did not ask them to ignore this fragile dependency, we did not ask them to just let the full traffic flow through to upstream repositories, and we wish they would've proactively made it their problem to cache/mirror - before a downtime incident.
• As quasi-customers of NPM (we pay them a tiny bit for some private packages, but that's irrelevant to 99% of our use as package consumers), we did not ask for the situation in which the whole ecosystem has a fragile dependency on one organization's (incredibly generous!) free registry service... it became dominant before the most recent 90%-95% of Node developers arrived.

[raulgomis]

Hi all! Sorry for the inconvenience caused. We (Bitbucket Pipelines) have just been able to contact one of the engineers at NPM and they whitelisted our IPs. It should be fine now. Let us know if you have any issue with it.

[joaomoreno]

Although that's pretty cool, what about the rest of us? We (VS Code) are still hitting this on pretty much every build. We use VSTS infrastructure: https://vscode.visualstudio.com/VSCode/_build/index?definitionId=1

[joemewes]

Need specific rate information to control our reelase/build/deploy cycle if this is an hourly/daily limit to API requests from NPM.

[guilouro]

Bitbucket already solved this issue

[JayCanuck]

BitBucket solved the issue for their whitelisted IPs, but I'd really appreciate any info on what the NPM registry limits are before npm ERR! 429 occurs so other services/devs can safeguard against the issue. Or even a process to whitelist our own IPs as trusted or something.

[Tyriar]

We're also seeing this issue on xterm.js (VSTS) https://xtermjs.visualstudio.com/xterm.js/_build?buildId=49

[IanSavchenko]

Travis CI also fixed https://www.traviscistatus.com/incidents/bbp3rj9jktnd 👏

[joaomoreno]

The issue appears limited to only those builds that use 'sudo: false'. We are working on determining what contributed to this and how to resolve it.

Very interesting. I wonder why that is.

[edmorley]

The sudo: false Travis jobs are run under docker on EC2 instances, so presumably have many jobs all sharing the same IP. The sudo: required jobs on the other hand, each run on their own GCE instance, so would have separate IPs. That said, we saw NPM connectivity issues on the latter too, so... 🤷‍♂️

[webdesignberlin]

cant login to npm on cli or web with same error: Too Many Requests