429 Too Many Requests

A 429 is the most polite error in HTTP. The service is working, it received your request, and it is telling you plainly that you are asking too often - Usually with a header saying when to come back.

It is also the error most often mistaken for an outage, because from a user's point of view "I cannot use this" looks the same regardless of why.

Rate limits and quotas are not the same

Both return 429 and they behave completely differently, which matters enormously for what you should do.

A rate limit is about speed: 100 requests per minute, 10 per second. It refills continuously or on a short window, so waiting a minute genuinely works.

A quota is about volume over a long period: 40 messages every three hours, 10,000 API calls a month. Waiting a minute does nothing; the reset is on a schedule you cannot influence.

Consumer AI services made this distinction visible to a lot of people who had never encountered it. "Too many requests in 1 hour" is a quota, not a rate limit, and refreshing does not help. The wording rarely makes the difference clear, and the surest signal is the reset time: If it is minutes, it is a rate limit; if it is hours or a date, it is a quota.

Reading the headers

A well-implemented 429 comes with information:

• Retry-After - Seconds to wait, or an HTTP date. The authoritative answer.
• X-RateLimit-Limit - The ceiling for the window.
• X-RateLimit-Remaining - How many you have left.
• X-RateLimit-Reset - When the window resets.

Those are conventions rather than standards and implementations vary, but the Remaining header is the useful one for a client: You can slow down before you are refused rather than after.

Why you hit a limit you did not earn

Limits are applied per something, and that something is often not you.

Per IP address is the most common for unauthenticated requests, and it means everyone behind the same address shares one budget. Offices, universities, mobile carriers using carrier-grade NAT, and every VPN exit node all put many people behind one address. If someone else on your network is hammering a service, you get the 429.

This is exactly what Google's "unusual traffic from your computer network" page is, and it is the single most common reason people believe Google is down when it is not.

Per account or API key is cleaner but has its own trap: A key shared across several applications hits a limit that no single application caused.

How to handle it properly as a developer

The wrong response is an immediate retry. That converts a rate limit into a self-inflicted outage: Every client retries at once, the service refuses them all again, and the retry storm consumes more capacity than the original traffic.

The right pattern is exponential backoff with jitter. Wait, double the wait on each failure, and add a random component so that a thousand clients that all failed at the same moment do not all return at the same moment. Cap the maximum wait, cap the number of attempts, and honour Retry-After over your own calculation whenever it is present.

Beyond retries: Cache aggressively so repeated requests never leave your process; batch where the API supports it; and if a provider offers webhooks, use them instead of polling. Most rate limit problems are really polling problems.

What to do as a user

1. Stop and wait. Refreshing extends the block on most implementations.
2. Work out which kind it is. Minutes means a rate limit; hours or a date means a quota.
3. Turn off your VPN. If the limit is per address and you are sharing an exit node with thousands of people, a direct connection may not be limited at all.
4. Try mobile data. A different address, for the same reason.
5. Sign in. Authenticated limits are almost always far higher than anonymous ones.

When a 429 really is a symptom

Occasionally a wave of 429s does indicate a problem. Services under strain sometimes tighten limits deliberately to shed load, so a sudden 429 on a request pattern that has always worked can be the first visible sign of an incident.

The tell is suddenness without a change on your side. If your usage has not changed and limits start being enforced that were never enforced before, check whether other people are reporting problems - You may be seeing load shedding rather than your own quota.