You can actually find the international standards definition for the 429 Too Many Requests error here. The purpose of this error message is to indicate to the user (whether real or scripted) that they’ve exceeded a rate limit for requests to the server – meaning, in simple English, that they’ve tried to access the server too many times within some predetermined amount of time.
According to The Internet Engineering Task Force, whose goal is to simplify and standardize the internet – and who defines different HTTP status codes for use throughout the internet, the 429 error code should include details explaining the condition (ie. ‘our site only allows 50 page loads per minute per logged in user. Please try again.’) and may include a ‘Retry-After header’ which would tell the user (or at least their browser) exactly how long to wait before making a new – and successful – request.
This rate limiting error is actually fairly new and hasn’t been implemented in all web servers or across internet services. This can lead to some confusion as different web servers or internet services may use their own internal codes for identical situations, such as Apache web server’s 509 HTTP code for ‘Bandwidth Rate Exceeded’ or Twitter’s API which had – in the past – incorporated a joke with their 420 ‘Enhance Your Calm’ error (which they later, after version 1 – thankfully – replaced with a standard 429 error).
The above image is a link to the Wikipedia article on HTTP response codes, but you can also read The Ultimate HTTP Error Code List here on ErrorCodesPro.com!
This guide intends to serve to illuminate the different common scenarios one might find themselves in if they’re looking to fix this error. While there are a plethora of different specific technical reasons for this error, this guide may just allow you to have a ‘jumping point’ from which to research your specific situation and lead you down the first few steps towards your answer.
Common Scenario: WordPress
If you’re running a WordPress site and your users are facing this rate limiting error code, fear not! We’re here to help you put the problems to rest, and give you the guidance you need to not worry about this type of issue again.
- Don’t panic! While there’s a technical issue that’s preventing users from using your site, there’s always a technical reason behind such a problem and there’s ALWAYS a fix. Depending on the hosting environment, your technical ability or resources close to you with technical ability, and the speed at which you can get support for your issue through your hosting provider or web server administrator, you may find yourself without this problem in no time at all.
- Check for any plugins that may be introducing (by design or by mistake) rate limiting onto your WordPress site. The easiest way to achieve this is to temporarily disable all of your plugins and then see if you and your users are still experiencing the rate limiting error. If this solves the issue, then slowly re-enable those disabled plugins until you can find the exact one that’s causing you distress. At this point in time, you’ll want to either look for an alternative plugin to achieve the same goal or contact that plugin’s support team.
- Ensure that your web server is not creating these error messages for your users. While WordPress traditionally uses Apache to run on the web, it’s worth reading on to the further sections in this article or – if you have limited access to the hosted environment where your WordPress site is hosted – it might be time to put in a support ticket or make a phone call asking for immediate assistance.
“For WordPress to be world class, it needs to have a sustainable model.” – Matt Mullenweg.
Common Scenario: Apache-Based Sites
Rate limiting of any kind is not natively supported by Apache. While Apache does have static server settings allowing you to control the maximum number of connections (and while, also, your supporting database will have like settings) none of these settings actually – by default – show a 429 error message. These are defined by any number of possible modifications to Apache, so we will review the possibly misbehaving mods now.
If you’re an Apache web server administrator (or have root access to your Apache server, no other resource more technical than yourself and you need to fix this pronto), then the culprit that’s giving out 429 error messages for rate limiting is likely one of:
- mod_evasive (which is designed to help you against DDoS attacks)
- mod_cband (which is designed for more ‘normal’ wear-and-tear types of bandwidth control – ie. larger sites that need to worry about such things)
or, far less likely to be one of:
- mod_limitipconn
- mod_bw
- mod_bwshare
- mod_qos
If you’re looking to fix your server from showing the rate limiting error message 429, you need to start your look at the configurations for the above Apache modules (whichever one you have installed).
Pro Tip: Depending on your operating system that your web server is installed on, you can see a list of Apache’s enabled modules by running one of:
apache2ctl -M
apache2ctl modules
a2query -m
httpd -M
ls /etc/apache2/mods-enabled/ (especially handy if you don’t have root access on a shared host)
If none of these work – Google is your friend for your specific situation.
Pro Tip #2: Google is always your friend. Don’t panic.
Common Scenario: APIs
On a much different side of the same coin, you may be running into error 429 while developing some piece of custom code, script or software that consumes an Application Programming Interface, or API. If that previous sentence sounded Greek to you – then this probably doesn’t apply. If, however, your brand new Twitter bot is asking Twitter’s API too often for the same information you may very well be hit with a 429 response code and no data. The horror!
The solutions? There are many ways that different common APIs deal with rate limiting. Let’s examine a few:
- User-level access to make individual requests. For the bigger and more popular social APIs like Facebook or Twitter, you’ll find that they will be far quicker to rate limit your App if the App itself is making the same call to the same resource too many times too quickly. However, if you instead build your App to consume user-level access (meaning, in plain English, that YOUR users login to YOUR app using THEIR Twitter/Facebook/whatever credentials via OAuth) then your individual users, while making calls to the API, will be far less likely to be rate limited.
- Make fewer requests. This sounds obvious – but most APIs are properly documented and will tell you exactly what API calls are rate limited by how many requests per however long of a period. If you read the documentation, and make changes to your code/script/App to ensure it absolutely never makes more than X many calls every Y seconds/minutes/hours/whatever – then you’ve properly solved your 429 error woes with that particular API.
- Contact the API vendor and ask them for an increase in your limited rate, or for them to lift the rate limiting restriction in your case. This might sound impossible – but if you describe the purpose of your code/script/App, the person/people/company who created the API might be willing (or willing for a fee, or a fee higher than your current plan…you’ve been warned) to consider lifting or increasing your rate limit.
Conclusion
If you’ve found this article while trying to fix error 429: Too Many Requests, then I hope I’ve been able to help you achieve your desired results and get your web server or code/script/App back up and running – at least by having given you some direction about where you can go to learn more about your specific issue. When in doubt – Google everything, and use the huge variety of knowledge on the internet to tailor a plan of attack that fits your exact and unique situation. While the information in, say, this serverfault question/response pair may not exactly illuminate how to fix this error, it can be deconstructed in order to provide you with your unique way of fixing the problem.
To be specific (and this is VERY specific, and most likely DOES NOT apply to your specific 429 error code) the above answer I’d linked to says to ‘change the HTTP_FORBIDDEN to HTTP_TOO_MANY_REQUESTS in mod_evasive20.c and compile again.’
The answer, in this specific scenario where this particular line of code for mod_evasive was changed to start generating 429 errors would be to do the exact opposite and recompile again. However – now you’re left battling HTTP 403 Forbidden, right? That’s actually great because there’s far much more information available – even here on ErrorCodesPro – on how to handle 403 Forbidden, and you’re one chain-link closer to identifying and solving the root cause of your issue!
The last 2-3 paragraphs dealt with a very specific kind of answer and – hopefully – demonstrated why it’s nearly impossible to detail every single answer for every single unique situation where we need to fix this error. I truly hope that somewhere in the depths of the internet is the answer to your specific, unique and (in a backward way) beautiful problem!
It truly is a very specific use of your ability to troubleshoot a problem when you try to fix an error as widely interesting and unique as the 429 rate limiting error. The first step is to calm down – don’t panic! – and then try to identify the root cause of the problem, and next find the appropriate solution for that problem. Afterward, you can look forward to having had properly identified and sorted a problem that literally has countless myriad possible causes – and you’ve managed to do it through the sheer power of research, testing and trying different solutions, and you’ve truly demonstrated your above-average troubleshooting skill. Bravo!
