Error 1015 You Are Being Rate Limited (Cloudflare) Fix

Problem

A page returns Error 1015: You are being rate limited on a Cloudflare screen, with a Ray ID at the bottom. Cloudflare stopped the request at the edge because your IP sent too many requests too fast.

Symptoms

• The Cloudflare page reads “You are being rate limited” with code 1015 and a Ray ID like 8a1b2c3d4e5f6789.
• The underlying HTTP status is 429 Too Many Requests — 1015 is Cloudflare’s branded version of a 429.
• It clears on its own after a wait (about 10 seconds on basic protection, longer on plans where the owner raised the cooldown).
• It tends to hit one IP or one network — a VPN, an office, a script — while other visitors sail through.

What This Error Actually Means

Error 1015 is Cloudflare saying a rate-limiting rule on this site is throttling your IP. It is not a firewall block and not an outage. A rule counted the requests coming from your address within a time window, that count crossed the configured threshold, and Cloudflare is now returning 429 until the window resets.

The thing to internalize: 1015 is about volume, and it’s temporary. That separates it cleanly from the codes it gets confused with. Error 1020 Access Denied is a firewall or WAF rule with a Block action — a decision about who you are (country, ASN, IP reputation, a pattern), and it won’t clear on its own. Error 1010 flags a browser signature as automated. A bare 429 with no Cloudflare page is usually the origin application’s own limiter, sitting behind Cloudflare. 1015 specifically means: Cloudflare’s edge rate limiter tripped on how many requests you sent.

Because it’s a threshold on request count, the fix splits by who you are. If you’re a visitor, you slow down or change the IP that’s being counted. If you own the site, the rule’s threshold, window, and matching criteria are yours to tune — and every trip is logged with the Ray ID, so you can see exactly which rule fired and on what path.

Top 3 Causes

1. A shared IP spending a collective budget - Corporate NAT, school networks, mobile CGNAT, and VPN exit nodes put many users behind one address. The rate limit counts per IP, so everyone’s requests add up and one busy user trips the limit for the whole pool. This is the most common 1015 real people hit.
2. A script, bot, or retry loop exceeding the rate - Automated requests, an aggressive crawler, a broken client stuck in a retry loop, or an integration polling too often blow past the threshold. Legitimate automation trips this constantly when it doesn’t pace itself or honor Retry-After.
3. A site rule set too tight for real traffic - The owner configured a rate-limiting rule with a low threshold or a narrow window, and normal usage — a page that fires many API calls, a burst of legitimate clicks — crosses it. This is the self-inflicted version, where the rule is catching customers, not attackers.

Diagnose with DechoNet

• HTTP Check to confirm the underlying status is 429 and to read the response headers. A Retry-After value tells you exactly how long the cooldown is; the cf-ray header ties your request to the Ray ID on the page.
• IP Lookup to see how your address presents — whether it reads as a datacenter, VPN, or shared/CGNAT range. If it does, a shared-IP budget is the likely trigger before you touch anything else.

Resolution Checklist

• Read the underlying status and headers. Confirm it’s a 429 and check Retry-After for the exact cooldown — often just seconds on basic protection.
• Wait, then retry with backoff. 1015 is transient; hammering it only refreshes the counter and extends your wait.
• Check whether you’re on a shared IP (VPN, office, mobile, CGNAT). Switch to a residential connection or drop the VPN — the count is per IP and will reset.
• Rule out a runaway client: a stuck retry loop, a browser extension, or a tab spamming an endpoint can spend your budget silently.
• If you own the site, find the Ray ID in the rate-limiting logs. Confirm which rule fired, on what path, and whether legitimate traffic is crossing a threshold set too low.
• As the owner, widen the window, raise the threshold, or scope the rule to the abused path only — and add an allow for trusted IPs (monitors, partner APIs) that shouldn’t be counted.

When to Escalate

• If legitimate users keep hitting 1015 on normal usage, escalate to whoever owns the Cloudflare rate-limiting rules — the threshold or window is too aggressive for real traffic and needs retuning, not disabling.
• If a monitor, webhook, or partner integration trips 1015, escalate to add its IP to an allow list; automated clients should be exempted from a rule aimed at abuse, not throttled alongside it.