429 Too Many Requests: what it means and how to fix it

02Is it a 429, a 503 or a challenge page?

The three get confused because all of them say, in effect, not now. Read the status code first, then the headers and the body.

03What does "Edge: Too Many Requests" mean?

This message has been widely reported on Yahoo and AOL sign-in pages: a Microsoft Q&A thread collects reports from Edge and Chrome users between October 2025 and January 2026, and Mozilla's bug 1992192 records it inside the Thunderbird mail client during Yahoo account setup. Despite the wording it has nothing to do with the Microsoft Edge browser: it comes from the service's own servers, its edge, which are most likely limiting sign-in attempts from your connection.

There is nothing to repair on your computer. Stop retrying, wait before signing in again, and check that no mail app or phone with an old password keeps trying to log in in the background, because those attempts keep the limit tripped.

04How to fix a 429 error as a visitor

• Wait: if the page shows a time or the response carries Retry-After, wait at least that long
• Stop reloading, and close other tabs that are polling the same site
• Turn off browser extensions that prefetch links, auto-refresh pages or check prices in the background
• Check other devices and apps on your connection: a script, a mail client or a sync tool can use up the limit you share with them
• Many people can share one public address, for example in an office or behind a mobile carrier; if the error keeps coming back, tell the site operator, who can see why the limit triggers

05How API clients should handle 429: Retry-After and backoff

Honour Retry-After first. RFC 9110 allows two forms: a number of seconds, as in Retry-After: 120, or an HTTP date, as in Retry-After: Fri, 31 Dec 1999 23:59:59 GMT. When the header is missing, wait with exponential backoff and random jitter, so that many clients that failed together do not retry together. An analysis on the AWS Architecture Blog found that full jitter, a random wait between zero and the exponential delay, substantially outperforms plain exponential backoff.

The function below does both. In a test against a local server, it waited 1 second twice after Retry-After: 1 and then succeeded, waited until the date given in an HTTP-date Retry-After, used short jittered waits when the header was absent, and returned a Retry-After: 3600 response at once instead of sleeping for an hour.

Retry only requests that are safe to repeat, such as GET, or POSTs protected by an idempotency key the API supports. Spend the budget evenly: an API that allows 100 requests per 60 seconds allows one every 0.6 seconds, so four parallel workers should each send at most one every 2.4 seconds. Many APIs announce their limits in x-ratelimit headers, and an IETF draft (revision 11, May 2026) is standardising RateLimit and RateLimit-Policy fields for the same purpose. From the command line, curl --retry treats 429 as transient and, since version 7.66.0, follows Retry-After; without the header, curl 7.88.1 waited 1, 2 and then 4 seconds in the same test.

// Retry after 429 or 503: honour Retry-After, else exponential backoff with full jitter.
// Node.js 18+ or a modern browser. Retry only requests that are safe to repeat.
export async function fetchWithBackoff(url, init = {}, { retries = 5, baseMs = 500, maxWaitMs = 60_000 } = {}) {
  for (let attempt = 0; ; attempt++) {
    const res = await fetch(url, init);
    if ((res.status !== 429 && res.status !== 503) || attempt >= retries) return res;

    const ra = res.headers.get("retry-after")?.trim();
    let waitMs;
    if (ra && /^\d+$/.test(ra)) waitMs = Number(ra) * 1000; // Retry-After: 120
    else if (ra && !Number.isNaN(Date.parse(ra))) waitMs = Date.parse(ra) - Date.now(); // HTTP date
    else waitMs = Math.random() * Math.min(maxWaitMs, baseMs * 2 ** attempt); // full jitter

    if (waitMs > maxWaitMs) return res; // asked to wait longer than this client allows
    await res.body?.cancel(); // release the connection before sleeping
    await new Promise((r) => setTimeout(r, Math.max(0, waitMs)));
  }
}

06How site owners should send a 429 (nginx example)

nginx's limit_req module rejects with 503 unless told otherwise, so set limit_req_status 429, and add Retry-After through a named error location because nginx does not send it by itself. In the test below, with rate=5r/s and burst=10 nodelay, 20 requests fired at once produced 11 successes and then 429s, the first request plus the burst, and the bucket refilled at five per second. Each rejection was logged at error level as "limiting requests, excess: ... by zone "api"".

The zone size is a short calculation: nginx documents that 1 MB holds about 8,000 states of 128 bytes on 64-bit platforms, so a 10 MB zone tracks roughly 80,000 client addresses.

Two traps are worth knowing. A location that answers with return is never rate-limited, because return runs in the rewrite phase and limit_req in the later preaccess phase: in the test, the same limit in front of return 200 let all 20 requests through. And behind a CDN or reverse proxy, $binary_remote_addr is the proxy's address unless the real client address is restored first, so every visitor would share one counter.

limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s;

server {
    listen 80;
    server_name api.example.com;

    location /api/ {
        limit_req zone=api burst=10 nodelay;
        limit_req_status 429;
        error_page 429 = @too_many;
        proxy_pass http://127.0.0.1:9000;   # your application
    }

    location @too_many {
        default_type application/json;
        add_header Retry-After 2 always;
        add_header Cache-Control "no-store" always;
        return 429 '{"error":"rate_limited","retry_after":2}\n';
    }
}

07Designing limits that do not catch real users

A good limit is invisible to normal use. Measure before enforcing: nginx's limit_req_dry_run (version 1.17.1 and later) counts excess requests without rejecting them, so the log shows who would have been limited. The choice of algorithm and key is covered in depth in what rate limiting is.

08What 429s cannot do: DDoS floods and search crawlers

A 429 stops only small floods. A per-client limit stops one noisy client, but a botnet spreads an HTTP flood across thousands of addresses that each stay under the limit, and every rejected request still costs the server a connection and a log line. Rate limits belong alongside filtering in front of the origin, not instead of it.

Mind search engines too. Google treats 429 like a server error and slows its crawling, so a limit that keeps answering Googlebot with 429 reduces how often the site is crawled.