What Is a 429 Too Many Requests Error?
A 429 Too Many Requests error is an HTTP status code that means you have sent more requests to a server in a given time than it allows, so it temporarily refuses further requests. It is the result of rate limiting, a protection that stops any one source from overwhelming a site. The response often includes a Retry-After header telling how long to wait. Common triggers include aggressive crawlers, buggy scripts, brute-force login attempts, or too many rapid page loads. The fix is to slow down and respect the limit.
- Status class
- 4xx client error meaning the user sent too many requests too quickly (MDN Web Docs)
- Mechanism
- Triggered by rate limiting to protect server capacity (RFC 6585)
- Helpful header
- Retry-After tells the client how many seconds to wait (RFC 9110)
- Common triggers
- Aggressive bots, runaway scripts, brute-force logins, API overuse
- Right response
- Back off, then retry gradually rather than immediately hammering again
What a 429 Too Many Requests error is #
A 429 Too Many Requests error means a client, a browser, bot, or application, has made more requests than the server permits within a set window, so the server is temporarily turning it away. This is rate limiting in action: a deliberate cap that protects a site from being overwhelmed by one source, whether that source is malicious or just misbehaving. The status code was defined specifically for this purpose (RFC 6585), and responses often carry a Retry-After header stating how long to wait before trying again (RFC 9110). Unlike errors that mean something is broken, a 429 usually means everything is fine except that you moved too fast. For a business, seeing 429s can indicate anything from an aggressive crawler to a buggy script or a genuine traffic surge. The correct response is almost always to slow down. If rate limits are blocking legitimate traffic on your own site, our /services/managed-hosting team can tune them appropriately.
Why servers use rate limiting #
Rate limiting exists to keep a site fast, available, and secure for everyone. Server resources, processing power, memory, and database connections, are finite, and a single source firing hundreds of requests per second can degrade performance for all other visitors or knock the site offline entirely. By capping how many requests any one client may make in a window, the server protects that shared capacity. Rate limiting also blunts specific attacks: it slows brute-force login attempts, frustrates content scrapers, and reduces the impact of denial-of-service traffic. Public APIs use it to enforce fair usage and to keep paid tiers meaningful. The trade-off is that a limit set too tightly can block legitimate power users or important crawlers, while one set too loosely offers little protection. Getting the threshold right is a balancing act informed by real traffic patterns. Tuning these limits so genuine visitors and search bots pass while abuse is stopped is part of the work on our /services/website-security page.
Common triggers for a 429 #
A 429 has a handful of usual causes. The most common on the receiving end is an aggressive bot or crawler that requests pages far faster than a human would, tripping the limit. Runaway scripts are another: a loop that calls an API without pausing can burn through an allowance in seconds. Brute-force login attempts deliberately hammer an endpoint and are met with 429s by design. Legitimate but poorly configured integrations, such as a sync job that fetches everything at once instead of in batches, frequently hit limits too. On the visitor side, refreshing a page rapidly, or many users behind a single shared IP such as an office network, can collectively exceed a per-IP cap. Content delivery networks and API providers each set their own thresholds, so the same behaviour may be fine on one service and blocked on another. Understanding which pattern is firing your 429s guides the fix. Our /services/api-crm-integrations page helps design integrations that stay within provider limits.
Reading the Retry-After header #
When a well-behaved server returns a 429, it often includes a Retry-After header that tells the client exactly how long to wait before trying again, expressed either as a number of seconds or as a specific date and time (RFC 9110). Respecting this header is the single most important thing a client can do, because retrying immediately only prolongs the block and wastes resources on both sides. A properly written script reads Retry-After, pauses for that duration, and then resumes. Some APIs also return headers describing the full limit, such as how many requests remain in the current window and when it resets, letting clients pace themselves before they ever hit a 429. Ignoring these signals is the difference between a brief, self-correcting slowdown and a client stuck in an endless loop of rejected requests. Building software that reads and honours these headers is central to reliable integrations, which is exactly what we focus on across our /services/api-crm-integrations work.
Handling a 429 with exponential backoff #
The professional way to handle a 429 in code is exponential backoff: wait, retry, and if it fails again wait longer, doubling the delay each time up to a cap. This gives the server room to recover instead of piling on more requests.
async function fetchWithBackoff(url, maxRetries = 5) {
let delay = 1000; // start at 1 second
for (let attempt = 0; attempt < maxRetries; attempt++) {
const res = await fetch(url);
if (res.status !== 429) return res;
// Respect Retry-After if the server sent it
const retryAfter = res.headers.get('Retry-After');
const wait = retryAfter ? Number(retryAfter) * 1000 : delay;
await new Promise(r => setTimeout(r, wait));
delay = Math.min(delay * 2, 30000); // double, cap at 30s
}
throw new Error('Rate limit: gave up after retries');
}When your own visitors see 429s #
If real customers or search crawlers are hitting 429s on your site, the rate limit is likely set too aggressively for your traffic. This shows up as complaints that pages fail to load under busy conditions, or as crawl errors in Search Console when Googlebot is throttled and cannot index your content properly (Google Search Central). Several factors can cause it: a security plugin or firewall with strict defaults, many legitimate users sharing one office or mobile-carrier IP, or a caching layer that is not absorbing enough traffic so requests reach the origin server directly. The fix is to review your rate-limit configuration and raise the thresholds for legitimate patterns while keeping protection against abuse. Allowlisting known good bots and your own monitoring tools helps too. Improving caching and server capacity reduces how often limits are needed at all. Our /services/speed-optimization and /services/managed-hosting teams handle exactly this kind of tuning so genuine traffic is never wrongly throttled.
429s, bots, and site security #
From a security angle, 429s are often a good sign that your defences are working, stopping scrapers, credential-stuffing attacks, and abusive automation before they harm your site. Rate limiting is one of the cheapest and most effective protections against brute-force login attempts, since it caps how many passwords an attacker can try. That said, sophisticated attackers rotate IP addresses to spread requests and evade per-IP limits, so rate limiting works best alongside other measures such as multi-factor authentication, CAPTCHAs on sensitive forms, and bot-detection services. The goal is to make abuse expensive and slow while leaving ordinary visitors untouched. Reviewing which IPs and paths are triggering the most 429s helps you distinguish an attack from a legitimate surge or a misbehaving partner integration. This layered approach, where rate limiting is one tool among several, is how we protect client sites on our /services/website-security page without degrading the experience for real customers and search engines.
Monitoring and responding to 429 patterns #
Watching the pattern of 429s tells you whether you are dealing with abuse, a misbehaving integration, or genuine demand you have outgrown. Server and firewall logs record which IP addresses, paths, and user agents are being throttled, so you can distinguish a single scraper from many real users behind one office network. If the throttling clusters on a login endpoint, it usually signals a brute-force attempt, and the right response is stronger authentication rather than looser limits. If it clusters on an API your own systems call, an integration is likely firing too fast and needs batching or backoff. If legitimate visitors and search crawlers are hitting limits during busy periods, your thresholds or capacity need raising. Setting up alerts on 429 spikes means you learn about the problem before customers do. Reviewing these signals regularly lets you tune limits with evidence instead of guesswork, keeping protection strong while never turning away real traffic. Our /services/managed-hosting team monitors and adjusts rate limits based on exactly this kind of real-world usage data.
Preventing and resolving 429 errors #
Preventing 429s comes down to two audiences: your own systems and outside clients. For code you control that talks to APIs, batch requests, cache responses, respect rate-limit headers, and use exponential backoff so you never flood a provider. For your website receiving traffic, set rate limits based on real usage rather than arbitrary defaults, allowlist trusted bots and monitoring, and lean on strong caching and adequate server capacity so limits rarely fire. When a 429 does occur, the immediate answer is to slow down and honour any Retry-After delay before retrying gradually. If you are the one being throttled by a third party, spreading requests over time or upgrading to a higher-tier plan usually resolves it. If your visitors are the ones seeing 429s, loosen overly strict rules and improve performance. For help either building well-behaved integrations or tuning your site's limits, our /services/api-crm-integrations and /services/managed-hosting teams cover both sides of the problem.
FAQ
What does a 429 Too Many Requests error mean?
It means you have sent more requests to a server in a short time than it allows, so it is temporarily refusing further requests. This is rate limiting protecting the server from overload or abuse. The fix is simply to slow down and wait, often for the number of seconds given in the Retry-After header, before trying again.
How long does a 429 error last?
It is temporary and clears once the rate-limit window resets. If the server sends a Retry-After header, it tells you exactly how many seconds to wait. Without that header, waiting a minute or two before retrying usually works. Repeatedly retrying without pausing only prolongs the block, so backing off is the fastest route to access.
Why is my website showing 429 errors to visitors?
Your rate limits are probably set too strictly, or a security tool, shared office IP, or weak caching is causing legitimate requests to pile up at the origin server. Review your rate-limit configuration, allowlist trusted bots and users, and improve caching and capacity so real visitors and search crawlers are not wrongly throttled during busy periods.
How do I fix a 429 error when calling an API?
Slow your request rate and implement exponential backoff: wait, retry, and increase the delay if it fails again. Honour the Retry-After header when present, batch requests, and cache responses to reduce calls. If you consistently need more throughput, consider upgrading to a higher API tier that offers a larger request allowance.
Can a 429 error hurt my SEO?
Yes, if search crawlers are being throttled. When Googlebot repeatedly receives 429s, it cannot crawl and index your pages properly, which can reduce your visibility over time. Check Search Console for crawl anomalies, allowlist legitimate search bots, and make sure your rate limits and server capacity comfortably accommodate normal crawling activity.
Is a 429 error a sign of an attack?
It can be. Bursts of 429s often mean rate limiting is blocking a brute-force login attempt, a scraper, or abusive automation, which is your protection working. But a legitimate traffic surge or a misconfigured integration can also cause them. Review which IPs and paths are triggering the errors to tell an attack apart from ordinary demand.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?