429 Too Many Requests

What It Means

HTTP 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. The server is intentionally refusing to process the request right now — not because anything is broken, but to protect itself from overload or abuse. The response usually includes a Retry-After header telling you how long to wait.

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1719500000

{"error": "rate_limit_exceeded", "message": "Too many requests"}

Common Causes

• Exceeding an API rate limit: Too many requests per second, minute, or hour
• Retry loops: A failing request retried in a tight loop without backoff
• High concurrency: Too many parallel requests from one IP or API key
• Shared API keys: Multiple services consuming the same rate budget
• WAF / DDoS protection: Cloudflare or similar throttling suspected abuse
• Brute-force protection: Repeated login attempts triggering a limit

How to Fix It

The right fix depends on whether you're the one being rate limited (client) or the one returning 429 (server).

If you're the client (calling an API)

// Respect Retry-After and use exponential backoff with jitter
async function fetchWithBackoff(url, opts, attempt = 0) {
  const res = await fetch(url, opts);
  if (res.status !== 429) return res;

  const retryAfter = Number(res.headers.get('Retry-After')) || 0;
  const backoff = retryAfter * 1000 || Math.min(2 ** attempt * 500, 30000);
  const jitter = Math.random() * 250;
  await new Promise(r => setTimeout(r, backoff + jitter));
  return fetchWithBackoff(url, opts, attempt + 1);
}

• Read the Retry-After header and wait before retrying
• Check X-RateLimit-Remaining and throttle before you hit zero
• Cache responses so you make fewer calls
• Batch or debounce requests instead of bursting

If you're the server (returning 429)

# Always send Retry-After so clients know when to come back
HTTP/1.1 429 Too Many Requests
Retry-After: 30

# Nginx rate limiting example
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;
}

429 vs Other Status Codes

How to Monitor for 429 Errors

A 429 from your own API means real users are getting throttled; a 429 from an upstream provider means your integration is being limited. UptimeSignal checks your endpoints on a schedule and flags non-2xx responses including 429, so you can adjust your request rate or raise limits before it impacts users. Pair it with response-time tracking to spot throttling early. See also API monitoring.

Frequently Asked Questions