429 Error Code (Too Many Requests): How to Fix It

The 429 status code, defined in RFC 6585 as Too Many Requests, means one specific thing: the server counted your requests over some window of time, you went over its threshold, and it is refusing to process more until the window resets. The practice is called rate limiting, and the response is a deliberate answer from software that is working correctly, not a crash. The same response may come from the application itself, from an API gateway in front of it, or from a CDN or web application firewall the site owner configured, which is why you can see a 429 on a site whose own servers never produced one.

Limits are counted against different things: an IP address, an account or API key, a session, or one specific endpoint. Which one applies decides which fixes below can work at all, so it is worth reading the response body and headers before reacting. A 429 is temporary by definition; the counter it reflects resets on schedule. It is also easy to confuse with neighboring status codes that ask for a different reaction.

That last row is worth its own page: when a site sits behind Cloudflare, the same refusal arrives branded as error 1015, produced at the edge before your request reaches the site's own servers.

A well-behaved 429 tells you exactly how long to wait. The Retry-After reference allows two formats: a whole number of seconds, or an HTTP date after which you may try again. Many APIs add quota headers alongside it. The names vary: RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset on newer APIs, the same names with an X- prefix on older ones, and fully custom conventions elsewhere, so the provider's documentation is the authority. This is what the throttled response looks like in the loopback lab this guide is built on, requested with curl after five rapid requests used up the window:

curl -sS -D - -o /dev/null http://127.0.0.1:8095/resource

HTTP/1.1 429 Too Many Requests
Retry-After: 10
RateLimit-Limit: 5
RateLimit-Remaining: 0
Content-Type: application/json

{"error":"rate_limit_exceeded","retry_after":10}

Two habits make every later fix easier. First, capture the full response once with curl -i or your client's logging rather than reacting to the status code alone; the headers usually name the quota you hit. Second, log your own request timestamps. Sustained rates are easy to estimate and easy to get wrong: a client that averages fifty requests per minute can still burst thirty requests in two seconds, and per-second thresholds only see the burst.

Fixes ordered by how often they are the real one. First, stop and wait. If the page or app shows a retry time, honor it; if not, a few minutes is a sensible default. Refreshing in a loop is the one guaranteed way to make things worse, because every reload spends more of the same budget and can keep extending the block.

Second, find the client that is actually spending the budget. Duplicate tabs of the same dashboard, a background sync client, an auto-refreshing page you forgot about, or a browser extension calling the same service all count against the same limit as your foreground clicks. Close the duplicates, then wait once.

Third, if the message names your account, plan, or API key, the limit is a usage quota rather than a traffic filter. Waiting still works when the quota window is short, but the durable fix lives in the provider's usage dashboard: spread the workload out, or move to a plan sized for it.

Fourth, consider who shares your public address. On office, campus, hotel, and mobile networks, address translation puts many people behind one public IP, and an IP-keyed limit counts all of them together. That is why you can be throttled while doing very little yourself. The browser IP diagnostic shows the address a site actually sees; if colleagues on the same network hit the same wall, you have found the cause, and the fix belongs to whoever runs the network, not to your browser.

Last, and only when a support page says the limit is session-keyed: clear cookies and site data for that site. It rarely helps elsewhere, and a genuinely IP-keyed or account-keyed limit does not care about your cache.

The contract for clients is simple: treat 429 as a signal, not an obstacle. When the response includes Retry-After, that value wins over anything your own code would invent; the server knows when its window resets and your algorithm does not. When the header is missing, fall back to exponential backoff with jitter: double the delay after each throttled attempt, cap it, and add a small random component so a fleet of clients does not resynchronize into simultaneous retry waves. Cap the attempt count as well and surface a real error when it is exhausted.

async function fetchWithBackoff(url, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(url);
    if (response.status !== 429) return response;
    const retryAfter = Number.parseInt(response.headers.get('Retry-After') ?? '', 10);
    const delayMs = Number.isInteger(retryAfter)
      ? retryAfter * 1000
      : Math.min(1000 * 2 ** attempt, 16000) * (1 + Math.random() * 0.1);
    await new Promise((resolve) => setTimeout(resolve, delayMs));
  }
  throw new Error('rate limited: retries exhausted');
}

In the lab, the retry that honored Retry-After: 10 succeeded on its first attempt after the wait, while an immediate retry inside the window was throttled again; the schedule the fallback produces stayed monotonic and capped at sixteen seconds. Retrying is only half the job, though. The stronger fix is not sending the burst in the first place: throttle at the client with a queue or token bucket sized under the published quota, cache responses that do not change between calls, use batch endpoints instead of per-item loops, and start scheduled jobs at a random offset rather than on the minute boundary every other cron job uses. Two details save real debugging time later: only auto-retry requests that are safe to repeat, attaching idempotency keys to writes, and remember that one quota is shared by every worker you run, so each instance needs its share of the budget, not a full copy of it. During development, React's StrictMode intentionally double-invokes effects, which doubles your API calls and trips tight limits early; deduplicate in-flight requests and cancel stale ones instead of turning StrictMode off.

When Retry-After is present, that is the answer, in seconds or as a date. Without it, the duration follows the window that was exceeded. Per-second and per-minute thresholds clear in seconds to about a minute; hourly or daily quotas refuse requests until the period resets, sometimes on a rolling basis and sometimes at a fixed clock boundary; throttles raised by a firewall's abuse rules typically hold for a few minutes and can extend if violations continue. The one universal rule is that hammering a throttled endpoint never shortens the wait, and against infrastructure that escalates on repeated violations it lengthens it.

If a limit still refuses requests long after any plausible window, stop guessing: check the provider's status page and documentation, because a stuck 429 is sometimes a provider-side incident or a quota accounting issue rather than anything your client did.

For collection work, rate limits are the source's published contract, and 429 is the source enforcing it. The workable response is architectural, not reactive. Set one request budget per source and enforce it across everything you run: every worker, every account, every region, every proxy exit. Distributing traffic across addresses does not reduce the aggregate load you place on the source, so the budget has to be counted where the requests originate, as the responsible collection framework lays out. Inside that budget, the same client techniques apply at fleet scale: jittered backoff on transient failures, capped retries, conditional requests, response caching, and deduplication so the same URL is not fetched twice for nothing.

A 429 from a source is a backoff signal, full stop. It is never a reason to switch exits, accounts, or fingerprints to keep the same traffic flowing; treating it that way violates the contract the limit expresses, and persistent refusals are a reason to stop and use an approved channel instead. Where managed proxy infrastructure legitimately fits is in how authorized workloads are built: stable regional egress for measurement and QA of your own properties, session-pinned exits so per-session state survives a whole workflow, and parallel regional coverage where each stream is paced within the budget on its own. The static versus rotating guide covers when each exit model fits a workload, the Python requests integration guide shows pacing and sessions in client code, and the proxy checker verifies an exit before production traffic. For paced, authorized collection at scale, managed residential and datacenter networks provide accountable egress; they do not expand any quota, and rotation is not a response to a 429.

Seen from the operator's side, a 429 your users or Google report is usually a rate rule you or your stack configured. The common causes, roughly in order: a CDN or WAF rate-limiting rule scoped too broadly, so one page view with dozens of images or API calls trips a per-IP threshold on asset paths; a security or login-protection plugin with aggressive defaults; a hosting plan's platform-level limiter; and only then an application limiter you wrote yourself. Genuine abuse also exists, which is why the goal is scoping, not deletion.

Diagnose by finding out which layer produced the response. If the origin's logs never recorded the throttled requests, the block came from the edge; the CDN's security event log will name the rule. Reproduce with curl -i against the affected URL and, when the edge is suspected, test once with the CDN temporarily bypassed for a low-traffic hostname to confirm the origin behaves. Then fix the scope: exempt static asset paths from per-IP page rules, size thresholds from real traffic percentiles rather than guesses, verify search-engine crawlers by the vendor's published verification method instead of trusting user-agent strings, and send an accurate Retry-After so well-behaved clients pace themselves.

Search impact is the quiet cost. Persistent 429s slow Googlebot's crawl of your site, and URLs that keep answering with them can be dropped from the index, as covered in Google's HTTP status guidance; watch Search Console's crawl stats after any rate-rule change. Reference documentation for scoping edge rules properly lives in Cloudflare's rate limiting rules, and equivalents exist for every provider. A limit that protects login endpoints while exempting your CSS is doing its job; one that throttles your own image directory is a bug you can fix in an afternoon.