TinyPingTinyPing

429 Too Many Requests: Check, Causes and Fixes

Check whether a URL answers 429 Too Many Requests right now, with response time and redirects, then fix the rate limit from the client side or the server side. Enter a URL such as https://example.com.

Common causes of 429 Too Many Requests

Your client ignores Retry-After

Most APIs that send 429 also send Retry-After, either as seconds or as an HTTP date. A client that retries immediately stays blocked and can extend the penalty. Read the header, wait at least that long, and only then retry.

Retries without backoff

A script that retries failed calls in a tight loop turns one 429 into hundreds. Use exponential backoff (wait 1, 2, 4, 8 seconds and so on) with random jitter, so several workers do not all retry at the same instant, and cap the number of attempts.

Many clients share one IP address

Rate limits keyed on IP count everyone behind the same address together: an office NAT, a mobile carrier, GitHub Actions runners or a serverless platform's shared egress. You may be blocked by traffic that is not yours. Authenticate with an API key where possible, so the limit applies to your account instead.

API quotas from Shopify, GitHub and others

Platform APIs publish their limits and how much is left, for example GitHub's X-RateLimit-Remaining and X-RateLimit-Reset headers, or Shopify's call limit and cost-based GraphQL throttling. Read those headers on every response and slow down before you hit zero, instead of waiting for 429.

Your own limit is too tight

nginx limit_req with a low rate and no burst, a Cloudflare rate limiting rule or an API gateway usage plan can block real visitors, for example a page that loads many API calls at once. Allow a burst (limit_req ... burst=20 nodelay), raise the threshold for authenticated users, and log what gets limited before enforcing it.

Limiting with 503 instead of 429

nginx's limit_req rejects with 503 by default, which tells clients and monitors the server is down rather than asking them to slow down. Set limit_req_status 429 and send Retry-After, so well-behaved clients back off on their own.

How to troubleshoot a 429

  1. Enter the URL and click Check status to see whether it is rate limiting a fresh client.
  2. If it returns 429 here too, the limit is global or broad, not just on your IP.
  3. Read Retry-After and any rate limit headers from the API's response.
  4. Back off on the client, or loosen the rule on your server, then check again.

What does 429 Too Many Requests mean?

429 Too Many Requests means the client has sent too many requests in a given amount of time, and the server is rate limiting it. It was defined in RFC 6585. The server is working; it is choosing to turn this client away for now.

A 429 may include a Retry-After header telling the client how long to wait. Many APIs also send headers showing the limit, how many requests remain and when the window resets. GitHub, for example, uses X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset.

Limits are counted per something: per IP address, per API key, per user or per endpoint. Knowing which one is the first step, because the fix is different. A per-IP limit can be hit by neighbours on a shared network, a per-key limit only by your own code.

For websites, search engines treat 429 like a temporary server error and crawl more slowly. That makes 429 a reasonable answer to an aggressive crawler, but a bad one for normal visitors and for Googlebot if it lasts long.

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 0
Content-Type: application/json

{"message": "API rate limit exceeded"}

When to check for a 429

Integrations that suddenly fail

A sync with Shopify, HubSpot or Google APIs starts failing. Check whether the endpoint is rate limiting you, and read Retry-After before scheduling the next run.

Testing a new Cloudflare rate limit rule

Confirm that a normal single request still gets 200 after you add the rule, so you only limit abusive traffic.

CI pipelines and scrapers on shared IPs

Builds on GitHub Actions or GitLab runners that download from a package registry or call an API can hit IP limits. Check from another address to see if the limit is on you or on the shared IP.

Protecting a login or API endpoint

You added limit_req to /login or /api. Check that normal requests pass and that the response code is 429, not 503.

Check something else

Frequently asked questions

How long do I have to wait after a 429?

If the response has a Retry-After header, wait at least that long. Without it, back off exponentially, starting at a second or two. Fixed windows often reset within a minute, but some APIs use hourly or daily quotas.

Is 429 an error on my side or the server's?

It is a 4xx code, so the server considers the client responsible: too many requests too fast. The fix is usually on the client. If you run the server and normal users get 429, the limit itself needs tuning.

Why do I get 429 on the first request?

Someone else on your IP address already used up the limit, for example on a VPN, an office network or a cloud provider's shared egress. Or the limit is per account and another of your scripts is using it.

Should my server return 429 or 503 when rate limiting?

429. It says the client should slow down, while 503 says the whole service is unavailable. Monitors, crawlers and API clients treat them differently, so the right code avoids false outage alerts.

Does 429 affect SEO?

Search engines slow their crawling when they see 429. Short bursts are harmless. If your rate limit catches Googlebot for long periods, new pages are discovered later and some may drop from the index.

Will monitoring my site trigger rate limits?

Not at a sensible interval. TinyPing sends one request every 5, 15 or 30 minutes per monitor, far below any normal rate limit.

Rate limits that misfire look like outages

A rule that is too tight blocks real customers while your own dashboard looks fine. TinyPing checks every 5 minutes from outside and alerts you when:

  • the URL returns 429 or another error code
  • the server times out or refuses connections
  • the endpoint recovers
Start monitoring free for 7 days

US$6.99 a month or US$47 a year per 50 monitors, team members free. 7-day free trial, no card needed.

Want alerts in team chat? Follow the guide for Slack or Google Chat.