# Update failing due to rate limiting by RubyGems **URL:** \ **Category:** Support\ **Created:** [June 16, 2017, 9:32pm UTC](https://meta.discourse.org/t/update-failing-due-to-rate-limiting-by-rubygems/64636 "2017-06-16T21:32:40Z")\ **Posts on this page:** 1\ **Showing post:** 26
**Author:** ![mpalmer](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mpalmer/32/45740_2.png) [@mpalmer](https://meta.discourse.org/u/mpalmer)\ **Post date:** [June 17, 2017, 2:19am UTC](https://meta.discourse.org/t/update-failing-due-to-rate-limiting-by-rubygems/64636/26 "2017-06-17T02:19:29Z")
> [@hnaseri](#): > > It doesn’t make sense to me why in such situations we need to talk to rubygems. Because they’re the ones rate-limiting your requests. > [@hnaseri](#): > > We are installing/Updating something that passes their thresholds. So I think their response would simply be for us to check the plugins we are trying to install. I have no idea what their response would be. I don’t presume to speak for rubygems, which is why I suggest talking to them, to find out what they _would_ say, and save all this guesswork. > [@pfaffman](#): > > Their site says: > > API and website: 10 requests per second It also says > Some endpoints may be cached by our CDN at times and therefore _may_ allow higher request rates. and > The [RubyGems.org](http://RubyGems.org) team may occasionally blackhole user IP addresses for extreme cases to protect the platform. Which means that the correct description of the rate limit is “10 requests per second, unless it isn’t”. Which is less than entirely helpful. > [@pfaffman](#): > > Is it possible that the bootstrap script is doing that as a matter of course? Here’s an excerpt from a build just now: If there were timestamps on that log, it would help to identify how quickly requests are actually being made. As it is, all we can see is “requests were made, and some got 429’d”. Also, according to that exerpt, as is, you got rate-limited after two successful requests, so either you’re hitting a blacklist (it’s hard to see how making three requests could get you to hit a 10 req/sec limit) or there’s other requests you didn’t show. Either way, though, without timestamps nobody can tell whether you might be hitting a limit or not. > [@pfaffman](#): > > I’ve read where you (or someone on team) said that you guys aren’t using any kind of proxy and rebuild all the time, so I can’t make sense of what I’m seeing. Exactly. We’ve got customers with some pretty monstrous plugin lists, and their rebuilds never get rate-limited that I’ve seen. Perhaps we do builds often enough that the CDN node we hit is kept constantly fresh with all the packages we need, which is… nice, I guess, but not helpful to anyone else. Which is why, if you _are_ seeing this problem, you should **talk to rubygems** so you _can_ make sense of what you’re seeing, because our pontificating on meta about what may or may not be going on isn’t going to get the problem solved. If rubygems comes back with some actionable advice as to how Discourse and its environs can be modified to work better with rubygems rate-limits, great. Let us know, and we’ll look into it. However, having someone from Discourse directly talk to rubygems isn’t going to help, because we’re not seeing the problem. We can’t provide any useful diagnostic data (such as source IPs, timestamps, or anything) to rubygems, nor can we describe how to reliably (or otherwise) reproduce the problem. So… once again, **if you are seeing rate-limiting problems with rubygems, talk to rubygems**. If you’re not willing to do that, then please don’t complain about being rate-limited here on meta, because all you’re doing is adding to the noise, not the signal, about this problem. --- _[View the full topic](https://meta.discourse.org/t/update-failing-due-to-rate-limiting-by-rubygems/64636)._