Cloudflare Error 1015: You are being rate limited

What’s actually happening

Requests start returning the 1015 page after a burst of activity. The block is time-boxed — anywhere from a few seconds to an hour depending on the rule's mitigation timeout — then it clears on its own. It mostly snares the wrong targets: your own API clients, webhooks hammering an endpoint, a polling cron, or a logged-in power user clicking fast. Real attackers rotate IPs and slip past it.

Common causes

• A Cloudflare Rate Limiting rule with a threshold lower than your real traffic (e.g. 50 requests/10s) tripping on normal bursts
• An API or webhook consumer sharing one egress IP, so all its calls count against a single bucket
• An aggressive crawler or scraper (yours or a third party's) requesting pages faster than the rule allows
• Many users behind one NAT/office/VPN IP collectively crossing the per-IP threshold
• Retry storms — a client that retries hard on errors, multiplying its own request count and self-throttling

How to fix it

1. Identify which rule firedCloudflare dashboard → Security → Events. Filter for the rate-limiting action around the time of the block. You'll see the rule, the threshold, and the IP/path that tripped it. Note the rule's "counting" characteristics and mitigation timeout — that's what you'll tune.
2. Raise or rescope the thresholdIn Security → WAF → Rate limiting rules, open the rule. If real traffic legitimately exceeds it, raise the request count or lengthen the period. Scope it more tightly — match a specific path (like /api/login) instead of the whole site — so normal browsing doesn't accumulate against an auth-focused limit.
3. Exempt trusted clientsFor your own API consumers and webhooks, add a bypass: a WAF skip/exception that matches a secret header or the client's known IPs so they don't count toward the limit. If you control the client, also slow it down — add backoff and respect Retry-After instead of hammering.
4. Wait it out if it's a one-offIf this is a visitor who just clicked too fast, no config change is needed — the block expires after the mitigation timeout. Tell them to stop refreshing and wait the stated window. If they're on a shared office IP, that's your cue the per-IP threshold is too low.