Should I just retry immediately?

No. Check the Retry-After header first — it tells you how long to wait, as seconds or an HTTP date. Retrying before then usually extends the block.

Is Cloudflare's 'Error 1015' the same as a 429?

It's related but distinct. 1015 is Cloudflare's own rate-limit block at the edge, before the request reaches your origin. A 429 from your origin means your application's own limiter fired.

Views: 13

429 Too Many Requests Checklist

Q: Who decides I sent too many requests?

RFC 6585 deliberately leaves it open. The server can count requests per resource, across the whole server, or across a fleet, and can identify you by IP, credentials, or a cookie. There's no universal rule.

429 Too Many Requests? Tell an origin rate limit from a CDN or WAF block in 3 checks: final status code, Retry-After, which layer responded. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The final response code for the request is 429 Too Many Requests.

Symptoms

HTTP Check shows a final status code of 429.
The block clears after a delay, then returns under sustained traffic.
It hits API clients, scrapers, CI pipelines, or users behind a shared IP harder than normal browsing.

What 429 Actually Means

RFC 6585 (§4, 2012) defines 429 as the user having “sent too many requests in a given amount of time (rate limiting).” The key word is user — this is about who is calling, not what’s broken on the server. The spec is explicit that it “does not define how the origin server identifies the user, nor how it counts requests”: a server may limit per resource, across the whole server, or across a fleet, and may key on IP, credentials, or a cookie.

Two practical consequences. First, the response MAY carry a Retry-After header — read it before retrying. Second, 429 responses MUST NOT be stored by a cache, so you can’t paper over one with caching.

Top 3 Causes

An application or API rate limit fired - You crossed a per-key, per-IP, or per-endpoint quota the origin enforces on purpose.
A CDN or WAF blocked you at the edge - Cloudflare’s “Error 1015,” a WAF rule, or bot protection rejected the request before it reached the origin. This is an edge decision, not an application bug.
A shared IP is being counted as one client - Office NAT, a VPN exit, or a CI runner pools many users behind one address, so a per-IP limit trips far sooner than expected.

Diagnose with DechoNet

HTTP Check to confirm the final code is 429 and inspect whether a Retry-After header is present.
IP Check to see the address you’re presenting — useful when a shared or VPN IP is the one getting rate-limited.

Resolution Checklist

Read the Retry-After value and wait that long before the next request.
Identify which layer responded — origin application vs CDN/WAF (Cloudflare 1015 points to the edge).
Add backoff and retry logic to clients so they slow down instead of hammering through the limit.
If you operate the limit, confirm the threshold and the identifier (IP vs key) match real usage patterns.
Check whether many users share one outbound IP and limit by API key or token instead.
Re-run HTTP Check after the window to confirm the response is no longer 429.

When to Escalate

Escalate to the API or platform owner if a legitimate workload is rate-limited by a threshold you can’t change.
If 429s come from a CDN or WAF, review the rate-limiting rules and allowlists with whoever manages the edge.