Guides
8 min readUpdatedError 1015 "You are being rate limited": what to do as a visitor or site owner
Quick answer
Error 1015, "You are being rate limited", appears when a website's rate limiting rule at Cloudflare counted too many requests from you in a short window and now blocks or challenges further requests for a while. The page is sent with HTTP status 429, and the site owner, not Cloudflare, sets the limit and how long it lasts. Visitors should stop reloading, close anything that refreshes the page automatically, wait, and contact the site if it continues.
01What does error 1015 mean?
Error 1015 is the page Cloudflare shows when a rate limiting rule stops a request, one of the 1xxx codes in the Cloudflare error codes reference. Its documentation states the cause plainly: the website owner configured rules that restrict how many requests a visitor can make in a given period, and the limit was exceeded. The owner's rule, not Cloudflare, decides who is limited.
The code sits in the page body and the status line carries 429; an owner who sets a custom response for a Block action can replace the page and choose another 4xx code. A 1015 is therefore one specific form of 429 Too Many Requests, and the idea behind it is explained in what is rate limiting. An unrelated "Unable to purge" message during cache purges reuses the number.
02What should I do if I see error 1015?
The block is temporary, and the reliable way out is to stop sending requests until it expires. Cloudflare's advice to visitors is to wait and not to retry repeatedly in a short period, because that may extend the block.
- Stop reloading. Every reload is another request against the same counter.
- Close whatever refreshes the page for you: auto-refresh extensions, many open tabs of the same site, a price checker, a script or a download manager.
- Wait. The page does not say how long; the owner chose the duration, and within Cloudflare's plan limits it can be anywhere from 10 seconds to a day.
- Expect it on shared connections. In offices, schools, hotels and on many mobile networks, other people's traffic can share your address and your counter.
- If it keeps happening, contact the website and give the time, the page address and the Ray ID printed on the error page. Only the owner can change who is limited.
03How long does a 1015 block last?
As long as the owner's rule says. A Cloudflare rate limiting rule has a counting period, a request threshold and a duration, also called the mitigation timeout, during which its action applies. The values an owner may choose depend on the plan, according to Cloudflare's documentation in October 2026.
| Plan | Counting period | Block duration | Rules | Counts requests by |
|---|---|---|---|---|
| Free | 10 seconds | 10 seconds | 1 | IP address |
| Pro | Up to 1 minute | Up to 1 hour | 2 | IP address |
| Business | Up to 10 minutes | Up to 1 day | 5 | IP address, or IP with NAT support |
| Enterprise | Up to 65,535 seconds | Up to 1 day, custom via the API | Up to 100, by contract | IP or IP with NAT support; many more with Advanced Rate Limiting |
04Why do real users get rate limited?
Rate limits count requests, not people, and two things inflate the count.
First, one page is many requests. A rule that matches every path counts the images, scripts and stylesheets along with the page, and only Business and higher plans can leave cached assets out of the count. A page with 40 assets is 41 requests when the browser has none of them cached. A visitor who opens five such product pages in new tabs within ten seconds sends up to 5 x 41 = 205 requests. Two tabs make 82 and three make 123, so a rule written as "100 requests per 10 seconds per IP" with page views in mind blocks them part-way through the third tab, from the 101st request.
Second, one address can be many people. Counters are kept per IP address by default, so everyone behind an office router, a school network, a VPN exit or a mobile carrier's shared address adds to the same counter. Thirty colleagues each loading one 41-request page in the same ten seconds produce 30 x 41 = 1,230 requests from a single address.
Counters are also kept per data centre rather than globally. The "IP with NAT support" option tells visitors behind one address apart with a cookie, but Cloudflare warns that visitors who block cookies or browse privately share one counter.
05Site owners: how to find the rule that fired
Start from the visitor's Ray ID and the time; the rule is recorded in the security events log:
- Open Security, then Analytics, then the Events tab, and filter by the Ray ID or the visitor's IP address. The time on the error page is UTC; convert it to the dashboard's time zone.
- Check Events by service, where rate limiting rules appear as their own service; the event shows which feature and which rule acted.
- Open the rule and note its expression, its characteristics (what it counts by), its period, its threshold, its action and its duration.
- Ask what legitimate traffic crossed the threshold, and how the rule can ignore it without ignoring abuse.
06How to scope a rate limiting rule so it spares real users
Most false 1015s come from rules that count the wrong thing. Match the symptom to the change; plan requirements are as documented in October 2026.
| Symptom | Likely cause | Change |
|---|---|---|
| Visitors blocked after a few page views | Static assets counted with pages | Match only dynamic paths, or stop counting cached assets (Business and up) |
| A whole office or school blocked at once | Counting by IP behind shared addresses | Raise the threshold, or count by IP with NAT support where available |
| Login users blocked while retyping passwords | Every POST counted, successful or not | Count only failed attempts, such as 401 or 403 responses (Business and up) |
| Uptime monitor or partner API blocked | Known clients share the public limit | Exclude their addresses with an IP list, or a Skip rule for all rate limiting rules |
| Search crawler slowed | Verified bots counted | Exclude verified bots; Cloudflare warns that limiting them can affect SEO |
| Bursts of clicks blocked | Window too short for normal bursts | Lengthen the period and raise the threshold in proportion, so short bursts average out (10 seconds is the shortest period offered) |
# match GET /status per IP, never counting addresses in the partner_ips list
http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in $partner_ips
# counting expression: only failed logins add to the counter
http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}07How to exempt monitoring and API clients safely
An exempted client can send unlimited requests, so every exemption should be as narrow as the job needs. Choose the action to fit the client as well: a challenge suits pages people browse, because a person can pass it and carry on, while APIs need a block with a clear 429, because an API client cannot complete a challenge and needs the status to back off.
- Exclude in the rule itself with a condition such as not ip.src in $partner_ips. Matching on source IP there needs a Business plan or higher; Free plans can match only path and verified bots.
- Or add a custom rule with the Skip action, set to skip all rate limiting rules, matching only the monitoring service's published addresses.
- Give API clients their own rule on the API path with a threshold sized for real clients. Counting by an API key header needs Advanced Rate Limiting.
- Never exempt by user agent alone: anyone can copy a monitoring tool's user agent.
08Error 1015 vs 429 vs a challenge page
These pages look alike but need different responses.
| What you see | Who generated it | What it means | What to do |
|---|---|---|---|
| Error 1015 page, HTTP 429 | Cloudflare's edge, enforcing the owner's rule | Too many requests in the rule's window | Stop, wait, contact the owner if it persists |
| Plain 429 Too Many Requests | The site's server, API gateway or another proxy | A limit set in the application or server, possibly with a Retry-After header | Honour Retry-After and slow the client down |
| 503 from nginx | The origin's nginx, whose limit_req module answers 503 by default | A server-side limit without a custom status | Wait; owners can set limit_req_status 429 |
| Challenge page | The edge, on a rule or bot check | The site wants proof of a real browser | Let the check run; allow challenges.cloudflare.com if it never loads |
| Error 1020, HTTP 403 | The edge, on a blocking security rule | Blocked, not rate limited; waiting does not help | Contact the owner with the Ray ID |
Questions
Frequently asked questions
Sources
Sources and verification
The nginx limit_req behaviour (status 503 by default and the error log line) was reproduced with nginx 1.22.1 on Debian 12, October 2026. Cloudflare plan limits, rule parameters and expressions are quoted from Cloudflare's documentation as published in October 2026; the expressions were not run against a live zone.
- 01Error 1015: You are being rate limited · Cloudflare docs
- 02Cloudflare 1xxx errors (HTTP status per code) · Cloudflare docs
- 03Rate limiting rules: parameters and availability by plan · Cloudflare docs
- 04Rate limiting parameters · Cloudflare docs
- 05How Cloudflare determines the request rate · Cloudflare docs
- 06Rate limiting best practices · Cloudflare docs
- 07Security Events · Cloudflare docs
- 08Skip options for custom rules · Cloudflare docs
- 09RFC 6585, Additional HTTP Status Codes, section 4: 429 Too Many Requests · RFC Editor
- 10Module ngx_http_limit_req_module · nginx.org
Last updated