How to Monitor API Rate Limits and 429 Errors

Q: What causes HTTP 429 Too Many Requests errors?

A 429 means the server's rate limiter rejected your request because a quota was exceeded — requests per second, per minute, per day, or a monthly plan allowance. Common triggers are traffic spikes, a deploy that removed client-side throttling, a retry loop without backoff multiplying load, several services sharing one API key, or a provider quietly lowering plan limits. The response often includes a Retry-After header or X-RateLimit-Remaining/Reset headers telling you when capacity returns.

Q: How can I detect rate limiting before users are affected?

Two patterns work together. First, canary checks: a monitor that calls the API at a known low rate — if even that sees a 429, your quota is exhausted and real traffic is being rejected. Second, headroom checks: a small scheduled job queries the provider's quota endpoint (like GitHub's /rate_limit) or reads X-RateLimit-Remaining from a normal response, and only pings a heartbeat URL when remaining capacity is above a threshold you choose. When headroom drops below the threshold, the ping stops and the alert fires — before the limit is hit, not after.

Q: Do retries fix 429 errors?

Only respectful retries. A retry with exponential backoff and jitter that honors the Retry-After header usually recovers gracefully from a brief burst. A naive immediate-retry loop does the opposite: every rejected request becomes several more requests, load multiplies exactly when the provider asked you to slow down, and a momentary limit becomes a self-inflicted outage — a retry storm. Some providers also penalize clients that keep hitting a limit, extending the lockout.

Q: Should I monitor my own API's rate limiter?

Yes, in both directions. An external monitor requesting your API at a normal, legitimate rate should never see a 429 — if it does, your limiter is misconfigured and blocking real users, which is a customer-facing incident even though your service is technically up. The reverse failure also happens: a config change silently disables the limiter and you only find out during the next abuse incident. Monitoring a canary endpoint at a known rate catches the first case cheaply.

Q: Which third-party APIs should I watch most for rate limits?

The ones woven into your critical paths: payment APIs (Stripe), messaging and email providers (Twilio, SES, SendGrid), LLM APIs (OpenAI, Anthropic — notorious for tight, tier-based token and request quotas), search and maps APIs, and platform APIs like GitHub or Slack that your automation depends on. LLM APIs deserve special attention because usage grows unpredictably and 429s arrive at the worst time — under peak load.

Rate-limit incidents are the strangest outages you will ever debug, because nothing is down. Every service is green, every process is running — and yet emails aren't sending, syncs are quietly skipping records, your AI features return errors under load, and a subset of legitimate users can't get through your own API. Somewhere, something is answering 429 Too Many Requests, and nobody is looking at it.

Rate limits sit in a monitoring blind spot: they are not errors in your code, they rarely appear in uptime dashboards, and they often bite background jobs first, where no user complains. This guide covers how to monitor both directions of the problem — third-party APIs limiting you, and your own rate limiter mistreating your users — with checks you can set up in minutes.

How rate limiting actually behaves

A 429 response means a quota was exceeded: requests per second or minute, tokens per day, or a monthly plan allowance. Providers usually tell you where you stand via headers — X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset (or the standardized RateLimit-* family), plus Retry-After on the rejection itself. Some providers never send a clean 429: you get 403s with a quota message in the body, or silently degraded responses. Our HTTP status codes guide covers where 429 fits in the wider taxonomy.

The dangerous part is the dynamics. Rate limits fail suddenly (everything works at 99% of quota and nothing works at 101%), invisibly (a nightly sync that gets limited just logs and moves on), and virally — a naive retry loop turns each rejection into several more requests, multiplying load exactly when the provider asked you to slow down. That retry storm is how a five-minute quota blip becomes an hours-long, self-inflicted outage.

Direction one: third-party APIs limiting you

Modern products are assembled from APIs — payments, email, SMS, LLMs, search, maps — and each one is a quota you can exhaust. As we covered in monitoring third-party dependencies, your users blame you, not the provider. Three checks give you coverage:

Canary checks. A monitor that exercises the dependency at a known, low rate — one request a minute against a cheap endpoint, using your production credentials. If a once-a-minute request sees a 429, your quota is fully exhausted and every real request is failing too. Expect a 200; alert on anything else.
Headroom heartbeats. The canary tells you when you have hit the wall; a headroom check warns you on approach. A small scheduled job queries the provider's quota endpoint (GitHub's /rate_limit, or simply reads X-RateLimit-Remaining off a routine response) and pings a CronAlert heartbeat URL only when remaining capacity is above your threshold — say, 20%. Below the threshold, the job skips the ping, the silence trips the alert, and you get paged before the limit, with time to act.
Keyword assertions on responses. For providers that degrade instead of rejecting, a keyword check asserting on a field only present in a full response catches quota-shaped degradation that status codes miss.

Give LLM APIs special attention. As we noted in monitoring AI and LLM API dependencies, token-based quotas are consumed unevenly, tier limits change, and usage grows faster than anyone plans for — 429s from your model provider under peak traffic are close to inevitable without headroom monitoring.

Direction two: your own rate limiter

Your rate limiter is security infrastructure, and it fails in two opposite ways. The loud failure is a misconfiguration that blocks legitimate traffic: a deploy tightens a limit, a shared corporate NAT pushes a whole customer office over an IP-based threshold, or a bug counts requests wrong — and real users start seeing 429s while every internal dashboard stays green. The quiet failure is the inverse: a config change silently disables limiting, and you discover it during the next scraping or credential-stuffing incident.

The first failure is cheap to monitor: point an external check at your API at a normal, legitimate rate — well inside your documented limits — and expect a 200 every time. That monitor sees exactly what a well-behaved customer sees; if it ever gets a 429, your limiter is hurting real users and you have a customer-facing incident regardless of what your infrastructure metrics say. Run it from outside your network (CronAlert checks from Cloudflare's edge) so it traverses the same limiter your users do. If you publish an API for customers, treat this check with the same seriousness as your endpoint monitors — for your integrators, a 429 storm is downtime, and it belongs on your status page when it happens.

Background jobs: where 429s hide longest

Interactive traffic complains; background jobs don't. A sync worker that gets rate-limited typically logs a warning, skips the batch, and reports a successful exit — and the data quietly drifts stale for days. This is the same visibility gap we cover in background worker monitoring, with a rate-limit twist: the job ran, so even job-level "did it run" checks pass.

The fix is to make partial success loud. Have the job ping its heartbeat URL only when it completed its work fully — not when it exited. A run that processed 40 of 2,000 records because the provider throttled it should skip the ping and trigger the silence alarm. If you batch heavy API work overnight, schedule it to respect quotas (spread requests, honor Retry-After), and let the heartbeat verify the schedule held; see batch job monitoring for the pattern.

Handle 429s properly while you monitor them

Monitoring tells you it's happening; your clients still need to behave. The rules are short: honor Retry-After when present, back off exponentially with jitter when it isn't, cap total retries, and put a circuit breaker in front of dependencies so a limited provider degrades one feature instead of consuming every worker thread in your app. And never alert-and-retry-forever silently — a dependency in sustained 429 is an incident to route through your incident response workflow, not a log line. Set alert thresholds so one transient 429 doesn't page anyone but a pattern does; our guide to alert fatigue covers the tuning.

A concrete CronAlert setup

Here is an end-to-end setup you can replicate after you create a free CronAlert account:

One canary monitor per critical third-party API. A cheap authenticated endpoint, checked every 1–3 minutes, expecting 200. A 429 here means the quota is gone.
One headroom heartbeat per metered quota. A small scheduled job reads the quota (dedicated endpoint or X-RateLimit-Remaining) and pings its heartbeat URL only while headroom exceeds your threshold.
A self-canary against your own API. External check at a legitimate rate, expect 200 — alerts when your limiter starts blocking real users.
Completion-gated heartbeats on API-heavy jobs. Ping only on full completion, so throttled partial runs trip the silence alarm.
Keyword assertions where providers degrade quietly. Assert on a field only present in complete responses.
Route alerts by severity. Headroom warnings to Slack or Discord; exhausted-quota canaries to PagerDuty or Opsgenie.

Everything above fits in CronAlert's free plan — 25 monitors with heartbeats, webhooks, and the full REST API included — and takes an afternoon to wire up for a typical stack of four or five metered dependencies.

Frequently asked questions

What causes HTTP 429 Too Many Requests errors?

A quota exceeded: per-second bursts, daily allowances, or monthly plan limits. Usual suspects are traffic spikes, retry loops without backoff, several services sharing one API key, and provider-side limit changes. Retry-After and X-RateLimit-* headers tell you where you stand.

How can I detect rate limiting before users are affected?

Pair canary checks (a low-rate monitor that should never see 429) with headroom heartbeats (a job that pings only while remaining quota is above threshold). The heartbeat's silence warns you on approach; the canary confirms exhaustion.

Do retries fix 429 errors?

Only with exponential backoff, jitter, retry caps, and respect for Retry-After. Naive retry loops multiply load into a retry storm that turns a quota blip into a sustained outage.

Should I monitor my own API's rate limiter?

Yes — an external check at a legitimate rate should never be limited. If it sees 429s, your limiter is blocking real customers, which is an incident even though everything is "up."

Which third-party APIs should I watch most for rate limits?

Whatever sits on your critical paths: payments, email/SMS, and especially LLM APIs, whose token-based quotas and fast-growing usage make 429s under peak load nearly inevitable without headroom monitoring.

Make 429s visible before your customers do

Rate limits break products while every dashboard stays green: jobs skip work silently, retry storms amplify blips into outages, and misconfigured limiters block paying users. A handful of canary monitors, headroom heartbeats, and completion-gated job checks make the whole class of failure visible — and all of it fits in CronAlert's free plan. Create a free CronAlert account and put a canary on your most critical API today.