Error 1015: You Are Being Rate Limited (How to Fix It)

Error 1015, with its one-line explanation "You are being rate limited", is Cloudflare's block page for a rate-limiting rule that the website's owner configured. The site sits behind Cloudflare's edge; the owner wrote a rule along the lines of "no more than N requests per time window per visitor" using Cloudflare's rate limiting rules; your address crossed the threshold; the edge served you the block page instead of the site. Underneath the branding it is the same mechanism as the generic HTTP 429 status, defined in RFC 6585: a counter, a window, and a temporary refusal once you exceed it.

Two properties define everything else in this guide. First, the block happens at the edge, before the request ever reaches the website's own servers. The recorded lab behind this article models exactly that architecture with an origin that logs what it sees behind a rate-limiting edge: during a burst of eight page requests, the origin's log recorded only the five that were allowed, and the three blocked ones never existed from the origin's point of view. Second, the rule and its thresholds belong to the site owner, not to Cloudflare and not to you, which is why every honest fix is either waiting, sending fewer requests, or talking to the owner.

It is also temporary by construction: the counter resets when the window ends. In the lab, the same request that was blocked answered normally again the moment the advertised wait elapsed.

The block lasts until the rule's mitigation window expires, and the owner chose that window when writing the rule. In practice most rules clear in seconds to a few minutes, which matches the lab model, where the block page carried a Retry-After of a few seconds and the first request after that wait returned 200. A minority of rules, especially on login and API endpoints, use longer mitigation periods, and some services layer their own account lockouts on top with waits measured in hours; when a site's own help pages name a specific number, that number wins.

Two behaviors decide whether you experience the minimum wait or much more than it. Requests sent during the block can keep the pressure visible: the fastest exit is to stop entirely, wait out the window once, then return at a calmer pace. And repeat offenses matter, because a visitor who trips the same rule every few minutes looks exactly like the automation the rule exists to manage, while one clean wait followed by normal browsing looks like the false positive it probably was.

To the recurring question, no, error 1015 is not permanent and it is not a ban. It shares a surface with genuinely different Cloudflare pages, though: error 1020 means an access rule matched you (a block by criteria, not by rate), and challenge loops are their own topic. If the page says 1015, it is a timer, and the timer ends.

The ranked list is short because the mechanism is simple. First, stop and wait: close the tab or leave the page alone for a few minutes, then try once. Refreshing during the block is counted traffic on some rule configurations and, more importantly, it resets nothing; a single clean retry after the window is the fastest path back in every time. Second, find what else on your side is spending the same budget: duplicate tabs of the same dashboard, an auto-refreshing page, a browser extension polling the site, or an app on your phone syncing against the same service all count toward one visitor's rate as the rule sees it. Close the duplicates before the retry, or the fresh window fills up again immediately.

Third, consider who shares your public address. Office, campus, hotel, and mobile networks put many people behind one address through shared network translation, and a per-address rule counts the whole crowd as one very busy visitor. That is the classic "1015 for no reason" case: it was not you, it was everyone behind your address combined. The browser IP diagnostic shows the address the site actually sees; when colleagues on the same network hit the block simultaneously, you have confirmed it, and the wait is unavoidable from that network.

Fourth, if the block recurs on a service where you are a paying or logged-in user, report it with timestamps. Owners tune thresholds from exactly these reports, and a legitimate user tripping a rule during normal use is information the owner wants.

No, and the reasons are worth stating plainly because the question is the most-asked one on this error. The counter lives on the server side of the edge; nothing in your browser, cache, cookies, or settings holds any piece of it, so no client-side cleanup clears a rate limit. The block page is not a malfunction to repair but a policy the site owner deliberately configured, and the limit is part of the site's terms of access in the most literal sense: it is the owner stating, in configuration, how fast they are willing to be visited.

Address-switching schemes, whether via VPNs, proxies, or hopping networks, do change which counter you hit, and this site sells proxies and still will not dress that up as a fix: presenting as a new visitor to continue traffic the owner just throttled is working around their stated limit, it violates most terms of service, and against per-path or account-keyed rules it does not even work. A block is a stop signal, not a routing suggestion; that principle holds across this entire cluster and it holds here.

What legitimately shortens your wait: sending fewer requests, spacing them out, closing the duplicate clients spending your budget, and, where you have a genuine need for higher volume, asking the owner. Sites with APIs publish quotas and paid tiers precisely for that conversation, and "we hit your rate limit doing X, can we get a sanctioned path" succeeds far more often than people expect.

When your own users report 1015, the rule is doing what you told it to do to the wrong people, and the repair is scoping, not deletion. The lab's checks map the three moves. First, scope by path: its edge rule counted page requests but exempted asset paths, so during a block the exempt request still returned 200. Real rules want the same shape, protecting login, search, and API endpoints while exempting static assets, because one image-heavy page can otherwise spend a whole per-address budget in a single load, which is exactly how galleries and dashboards lock out their own visitors.

Second, size thresholds from measured traffic rather than instinct: your analytics know how many requests a real page view costs and how fast your busiest legitimate users click, and the rule should sit above the honest percentiles with room to spare, then descend as evidence justifies. Remember shared addresses while sizing: a per-address threshold that fits one home user is five times too tight for a small office behind one address. Third, use the edge's own visibility: because blocked requests never reach the origin, your origin logs cannot show the problem, and the security event log at the edge is where matched rules, matched paths, and affected addresses are recorded. The lab's origin-log check is that lesson in miniature.

Last, verify legitimate crawlers by the search engines' published verification methods and exempt them properly, rather than either blanket-trusting user-agent strings or letting a tight rule quietly throttle indexing, which surfaces weeks later as unexplained search decline.

For collection work, a 1015 is the source's contract enforced in configuration, and the correct engineering response is identical to the 429 discipline it inherits from the underlying status code: honor the wait, back off with jitter, cap retries, and treat repeated blocks as a stop condition rather than an obstacle course. One request budget per source, enforced across every worker, account, region, and exit you run, remains the aggregate rule, because distributing traffic across addresses does not reduce the load you place on the source; the responsible collection framework is the full statement of that discipline.

Rotation deserves its own sentence in this specific context: rotating exits in response to a rate-limit block is identity-switching to continue refused traffic, and it is exactly what this cluster's stop-condition rule prohibits. The static versus rotating guide covers what rotation is legitimately for, and "outrunning the counter" is not on the list. Where managed proxy infrastructure legitimately fits is the same place as always: accountable regional egress for authorized workloads that are paced within the source's published limits from the start, with session-pinned exits so per-session state survives a workflow, and budgets set so the edge rule never fires at all.

The most useful habit is treating first-1015 as a design review trigger: measure what rate tripped it, halve your pace, widen your caching, and check whether the source offers an API or export that makes the whole question moot. A pipeline that never sees the block page is cheaper than one that handles it well.