In short. Error 1015 is not something Cloudflare decided about your site — it is a rate limiting rule you configured, firing. The threshold, the counting method and the block duration are all yours. When real visitors see it, the rule is almost always counting the wrong things: a single page load can be dozens of requests, and thousands of mobile users can share one address.
The rule is yours, and so is the fix
Cloudflare returns 1015 when a request crosses a threshold defined in a rate limiting rule on your own account. Nothing about it is automatic or imposed. You chose how many requests, over what window, counted by what, and how long the block lasts.
That matters because it reframes the problem. There is no setting to "turn off Cloudflare's rate limiting" — there is a rule you wrote that is matching traffic you did not intend it to match. The work is to find that rule and narrow it.
If legitimate visitors are seeing 1015, the rule is not protecting you from them — it is failing to distinguish them from what you meant to stop. Raising the threshold makes the symptom rarer without making the rule any better at telling the two apart.
Why most of what is written about 1015 does not help you
Search the error and the results are dominated by companies selling scraping and proxy infrastructure. That is not an accident — their readers are trying to get past rate limits, so their articles are written for the party on the other side of your rule.
The consequence is that almost nothing addresses the question a site owner actually has: which rule fired, on what request, and how do I make it stop catching customers. This article only covers that side. If your visitors are being blocked, you do not need a workaround; you need the rule corrected, and you are the only person who can do it.
First, confirm it really is 1015
Three different mechanisms produce superficially similar blocks, and they live in different parts of the configuration:
| What the visitor sees | Mechanism | Where it is configured |
|---|---|---|
| Error 1015, "you are being rate limited" | A rate limiting rule crossed its threshold | Rate limiting rules |
| Error 1020, "access denied" | A firewall or WAF rule matched | Firewall / WAF rules |
| Plain HTTP 429 from your application | Your own code or web server limiting | Application or nginx configuration |
# What is actually being returned, and by whom?
curl -sS -o /dev/null -D - https://example.com/api/search \
| grep -iE '^(HTTP/|cf-ray|retry-after|server):'
# A cf-ray header with a 429 or 403 means the edge answered, not your origin.If there is no cf-ray header the block came from your own stack and the edge is not involved — that path is covered in the API rate limiting guide. Error 1020 is a different rule type entirely and is covered in the 1020 guide.
Find the rule that fired
Every blocked request carries a Ray ID, and the security events view in your Cloudflare dashboard can be filtered by it. That single lookup tells you the rule name, the matched request and the counting characteristic — which is the whole diagnosis.
Ask the affected visitor for the Ray ID shown on the error page, or reproduce it yourself and read it from the response. Then look at three things about the matching rule: what path expression it covers, what it counts by, and what threshold and window it uses. Almost every false block is explained by the first two rather than the third.
Five configurations that rate-limit real people
1. Counting every request instead of the meaningful ones
A single page view is not one request. It is the document plus stylesheets, scripts, fonts, images and any background calls — routinely thirty to sixty. A rule allowing "fifty requests per minute" against a path expression that matches everything therefore allows roughly one page view per minute.
# How many requests does one page view actually make?
curl -sS https://example.com/ \
| grep -oE '(src|href)="[^"]+"' | wc -lScope the rule to the endpoint worth protecting — a login form, a search endpoint, an expensive API route — rather than to the whole site. Static assets should almost never be counted.
2. Counting background polling as user activity
Dashboards that refresh, live-tail views, autocomplete fields and notification pollers generate steady request streams from a single genuine user. A rule tuned for human browsing will catch anyone who leaves your dashboard open.
Either exclude those endpoints or give them their own rule with a threshold matching how often the client is designed to call them.
3. Counting by IP address when many people share one
This is the cause behind most reports of "one customer keeps getting blocked". Counting by client address assumes one address is one user. Frequently it is not:
- Corporate networks present hundreds of employees behind a single address.
- Mobile carriers use carrier-grade NAT, so thousands of subscribers can share one address.
- Schools, hotels and public wifi do the same at smaller scale.
- Some privacy networks and VPNs concentrate many users on few addresses.
When the counting characteristic is the address, all of those users are treated as one visitor and blocked collectively. For endpoints where you can identify the user — an authenticated API, a session — counting by something more specific than the address is what makes the rule fair.
4. A rule scoped to the whole site
Rate limiting is a targeted instrument. A rule matching every path applies the same budget to a visitor reading three articles and to something hammering your search endpoint, and the only threshold that lets the first through is one the second never reaches.
Write one rule per endpoint that needs protecting, with a threshold derived from how that endpoint is legitimately used. Two narrow rules almost always outperform one broad one.
5. Your own infrastructure tripping it
Uptime checks, synthetic tests, deployment smoke tests and internal integrations all hit your site on a schedule. If they are not excluded, they consume the same budget as visitors — and worse, a monitoring check that receives 1015 will report your site as down while it is serving everyone else correctly.
Exclude your own checkers explicitly. If you monitor from several regions, exclude each of them, and re-check after adding a region. Scheduled monitoring makes this visible quickly: a check that starts failing at a fixed interval while manual visits succeed is almost always your own rule.
Scoping a rule so it protects without blocking
Four questions, answered in order, produce a rule that behaves:
- What am I protecting? Name the specific endpoint and the specific abuse. "The login form against credential stuffing" is a rule you can write. "The site against bots" is not.
- What does legitimate use look like? Measure it. The threshold should sit above the busiest genuine user, not at a round number that felt safe.
- What should it count by? The address is the default and the crudest option; anything that identifies a session or account is fairer wherever it is available.
- What should happen on a match? Blocking is the harshest response. A challenge or a managed response lets a real person continue while still costing an automated client.
Set the block duration deliberately. A long block turns a brief burst into an outage for that visitor, and because the counter usually keeps running, an active client can extend its own block indefinitely — which is why a legitimate user sometimes reports being locked out "for hours" after a single mistake.
Test the rule before you trust it
A rate limiting rule is one of the few configurations that only reveals its behaviour under conditions you would rather not meet by accident. Test it deliberately, against your own site, from an address you control.
# Deliberately exceed your own threshold on your own endpoint and watch
# where the response changes. Use a low count first; you are testing a rule,
# not load-testing the site.
for i in $(seq 1 25); do
printf '%s ' "$(curl -sS -o /dev/null -w '%{http_code}' https://example.com/api/search?q=test)"
sleep 0.2
done; echoYou are looking for two things: that the rule fires where you expect, and that an ordinary page view does not approach the threshold. If a single normal visit consumes a noticeable share of the budget, the scope is wrong regardless of what the number says.
What to do when a customer reports it
- Get the Ray ID from their error page — it identifies the exact request.
- Look up the security event and read which rule matched and what it counted.
- Check the counting characteristic before anything else. If it is the address and the customer is on a corporate or mobile network, you have the answer.
- Check the scope. If the rule matches static assets or background polling, narrow it.
- Only then consider the threshold, and derive it from measured legitimate use rather than raising it until complaints stop.
Raising the number first is tempting because it works immediately. It also removes the protection you configured the rule for, which you will discover the next time the endpoint is actually abused.
How to check your site right now
Use the HTTP header checker to see exactly what the edge returns for a given path, including whether a cf-ray header is present and whether a retry-after is being sent. The redirect tracer helps when the block appears only after a hop, and the speed check shows how many requests a single page view actually makes — the number that most often explains a threshold being crossed by ordinary use.
Because a rate limiting block is intermittent by design, it is easy to miss in manual testing and easy to misattribute to an outage. Scheduled monitoring records the status code of every check, so a rule that starts catching your own checker appears as a pattern at a fixed interval rather than as a mysterious downtime report.
Frequently asked questions
Can I turn off Cloudflare's rate limiting?
There is nothing imposed to turn off. 1015 comes from a rule in your own configuration, so the action is to find that rule and either narrow it or remove it. If you did not create it, someone with access to the account did.
How long does the block last?
For exactly as long as the rule specifies, because you chose that duration. If a user reports being blocked far longer than the configured period, check whether their client is still retrying — continued requests during a block commonly keep the counter alive.
Why does one customer keep hitting it and nobody else?
Most often because they are behind a shared address — a corporate network or a mobile carrier — so the rule counts an entire population as one visitor. Check the counting characteristic before assuming anything about that customer's behaviour.
Is 1015 the same as HTTP 429?
429 is the standard status code for rate limiting and can come from anywhere in the stack. 1015 is Cloudflare's branded page for its own rule firing at the edge. The presence of a cf-ray header is what tells you which one you are looking at.
My uptime monitor reports the site down, but it opens fine for me.
Classic symptom of a rule catching your own checker. Monitoring hits the same path on a fixed schedule from a small set of addresses, which looks exactly like automated traffic. Exclude your checkers, and re-check after adding a monitoring region.
Should the rule block, or challenge?
Blocking is appropriate when you are certain the traffic is unwanted. Where legitimate users can plausibly be caught — anything counted by address — a challenge is safer: a real person continues after a moment, and automated clients still pay a cost.
Checklist
- Confirm the block is 1015 and not 1020 or an application 429.
- Get the Ray ID and read the matching security event.
- Check the counting characteristic before the threshold.
- Scope rules to specific endpoints, never to the whole site.
- Exclude static assets from counting.
- Give polling endpoints their own rule matched to their design.
- Remember that one address can be an office or a mobile carrier.
- Exclude your own monitoring, and re-check after adding a region.
- Prefer a challenge over a block wherever real users can be caught.
- Test the rule deliberately instead of discovering its behaviour from complaints.
