How to Fix Cloudflare Error 1015 (Rate Limited)

By ErrorFix · Updated October 13, 2026 · 6 min read

What Error 1015 means

Error 1015 is Cloudflare's "slow down" message. Site owners can create rate-limiting rules that say, in effect, "no single visitor may request this page more than X times per minute" — a defense against scrapers, brute-force logins, and traffic spikes. When your requests cross that line, Cloudflare answers with a 1015 page instead of the site, usually with the words "You are being rate limited."

The key detail is that the limit is normally counted per IP address, not per person. That is why the error feels so unfair when you are "just browsing": if you share Wi-Fi at home, an office, a dorm, a cafe, or a VPN exit node, everyone behind that public IP shares one allowance. One person hammering refresh, or one browser extension syncing aggressively, can get the whole household timed out. And note that 1015 is the rate-limit error — it is different from Error 1020 (Access Denied), which means the site's firewall rule blocked you outright rather than slowing you down.

Common causes

• Rapid manual refreshing: reloading a page over and over during a sale, a drop, or a live event is the classic way visitors trigger a 1015.
• Auto-refresh extensions and scripts: page-monitor tools, auto-bid scripts, download managers, and aggressive sync extensions fire requests on a timer you may have forgotten about.
• Shared IP addresses: dorms, offices, cafes, mobile carrier NAT, and VPN exit nodes put many people behind one IP — their traffic counts against your limit too.
• Strict owner thresholds: the site owner set the rule too tight, so normal browsing (search pages, dashboards, checkout flows) trips it for regular visitors.
• Scrapers and bots hammering the endpoint: a crawler gone wild or an attack can push the rule to fire for everyone, legitimate visitors included.

How to fix Error 1015 — step by step

Steps 1 and 2 are for visitors. Steps 3 through 6 are for site owners.

1. Visitor: stop and wait — do not keep refreshing. Close the tab and wait at least one to five minutes before trying again. Every new request resets the rate-limit window, so hammering refresh actually makes the block last longer. Put the phone down, grab a coffee, and come back — for a normal browsing session the block almost always clears on its own within a few minutes.
2. Visitor: check what on your end is firing requests so fast. Open your browser and count: do you have the same page open in multiple tabs, an auto-reloading extension, or a download manager hitting the site? Close extra tabs and pause any extensions or scripts that hit the site automatically. If you share Wi-Fi with family, office, or dorm traffic, someone else may have tripped the limit on your shared public IP — try mobile data once to see if a different IP gets through.
3. Site owner: find which rate-limiting rule fired. Log in to Cloudflare, open your domain, then go to Security, then Events. Filter by the recent 1015 responses and note which rate-limiting rule matched, the IP address, the path, and the request rate. This tells you exactly what tripped the limit — one visitor reloading a page fifty times, a scraper hitting an API endpoint, or your own cron job — so your fix targets the cause instead of a guess.
4. Site owner: tune the rule's threshold and period. In Cloudflare, go to Security, then WAF, then Rate limiting rules, and open the rule from the previous step. If the threshold is too strict for normal use — for example it blocks anyone making more than a handful of requests per minute — raise the request count or lengthen the period. For endpoints humans refresh a lot (search pages, live dashboards, checkout), set a higher limit. Click Save and Deploy, then test from a fresh session. Rate limiting is a paid Cloudflare feature, so confirm your plan actually includes the rule you are editing.
5. Site owner: allowlist trusted traffic and exclude bots. Still in the rate-limiting rule editor, add exclusions so the rule does not fire on traffic you trust: your office and home IPs, your uptime monitor, and well-behaved crawlers. If a bot or scraper is hammering one endpoint, consider a separate stricter rule for that path instead of raising the limit everywhere — that keeps aggressive traffic blocked while normal visitors sail through. Also check Security, then Bots: a misconfigured bot-management score can stack on top of rate limiting.
6. Site owner: handle the traffic behind the limit. If the events log shows the limit was tripped by a genuine surge — a viral link, a sale, a scraper gone wild — fix the underlying load. Block the offending IP or ASN with a WAF custom rule (Security, then WAF, then Custom rules), cache the hammered endpoint (Caching, then Cache Rules) so repeated hits serve from Cloudflare's edge instead of your origin, and consider throttling your own scheduled jobs and scrapers. Re-check the events log after 24 hours: a 1015 that keeps firing on new IPs means the rule is still too tight, not the visitors.

Did this fix it? Quick checklist

• The page loads after waiting a few minutes with no new 1015
• No auto-refresh extensions or extra tabs are firing requests
• Testing on a different network (mobile data) gets through
• Owner-side: the rate-limit threshold fits normal browsing, and trusted IPs are excluded

If you are a visitor and the 1015 keeps returning every time you browse normally, the site owner's rule is too strict for real traffic — report it to the site through its contact page or social channels and mention that legitimate visitors are hitting the rate limit. If you are an owner and the block keeps catching real users, resist the urge to simply delete the rule: tuned limits with proper exclusions stop scrapers while letting humans through, and deleting protection entirely invites the bots you built the rule to keep out.