Cloudflare Error 1015 “You Are Being Rate Limited”: Causes and Fixes

Cloudflare's 1xxx codes each name the component that acted. 1015 is the rate limiter; its sibling 1020 is a firewall rule that never expires on its own. Mixing them up is the most expensive mistake here — one needs patience and pacing, the other needs a different request.

How a Cloudflare rate limiting rule works

A site owner defines three things: which requests count (for example, anything under /api/ or every POST to /login), how they are grouped (per IP by default), and the threshold — a number of requests within a counting period. Cross it, and Cloudflare applies the action for the mitigation period the owner chose.

How long does error 1015 last?

As long as the owner's mitigation timeout — commonly between ten seconds and an hour. If the response carries a Retry-After header, that is the number to wait. If not, back off exponentially from about thirty seconds and stop once a single request succeeds. Hammering the endpoint while blocked does not shorten the timer, and some rules count blocked requests too, so persistent retries keep you over the threshold indefinitely.

Fixing it as a normal visitor

1. 1Wait a few minutes, then reload once — not repeatedly.
2. 2Close duplicate tabs of the same site. Auto-refreshing dashboards and open tabs all count toward one limit.
3. 3Pause extensions that prefetch or poll, such as price trackers and link previewers.
4. 4Leave shared networks — office, university or mobile carrier NAT — where hundreds of people share your public IP and its budget.
5. 5If it persists, contact the site with the Ray ID. Only the owner can see which rule fired and whether it is set too tight.

Fixing it as a developer or scraper

For automated traffic, a 1015 is useful information: you now know roughly where the threshold is. The fix is to stay under it, which means pacing first and spreading load second.

import random
import time
import requests

def polite_get(session: requests.Session, url: str, max_tries: int = 5):
    delay = 30
    for _ in range(max_tries):
        r = session.get(url, timeout=30)
        if r.status_code != 429:
            return r
        wait = int(r.headers.get("Retry-After", delay))
        time.sleep(wait + random.uniform(0, 5))
        delay = min(delay * 2, 900)
    raise RuntimeError(f"still rate limited after {max_tries} tries: {url}")

• Measure the threshold, then run at 60–70% of it. Slowly increase concurrency until the first 1015, note the rate, and back off well below it.
• Add jitter. Perfectly regular intervals are easier to spot than the threshold itself.
• Cache and deduplicate. The cheapest request is the one you do not send twice.
• Prefer the site's API or sitemap. They are often under a looser rule than the HTML front end.

Does rotating proxies fix 1015?

Only when the rule counts by IP address. Then each exit has its own budget, and spreading requests across a rotating residential pool multiplies the rate you can sustain. When the rule counts by something else, a new IP inherits the same counter:

If you own the site

1. 1In Security → Events, filter to the rate limiting rule and check who it is catching.
2. 2Raise the threshold or narrow the expression if real customers appear — shared corporate and carrier IPs are the usual collateral.
3. 3Count by session cookie or API key rather than IP where users sit behind NAT.
4. 4Use a managed challenge instead of a block for borderline traffic, so humans get through.
5. 5Exclude your own uptime checks, webhooks and monitoring before they trip the rule.