If Cloudflare error 1015 appears while browsing or using a feature, stop rapid retries and keep the failed address and time. The site owner sets the visitor rate-limiting rules. Owners should compare the matched rule with the actual request pattern, including background requests a single visible action can generate.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Identify the request burst that triggered the limit
| Situation | Useful next step | What to avoid |
|---|---|---|
| Visitor temporarily blocked | Wait, then report persistent failure to the owner | Repeated rapid refreshes |
| Normal search or form use blocked | Compare scope and request count with the intended workload | Choosing a threshold without evidence |
| Integration repeatedly triggers a limit | Review its expected call pattern | Treating every call as a manual visit |
| Management message says Unable to purge | Use cache-purge troubleshooting | Assuming this is the visitor block |
What a visitor can do
Allow some time before trying the page again. Cloudflare advises against repeatedly retrying within a short period because that may extend the block. Rapid refreshing is unlikely to help explain the problem.
If access remains blocked, send the website owner the page address, approximate time, and error screenshot. Describe what you were doing just before the message appeared, such as searching products or opening several pages. That context helps the owner reproduce normal use without assuming that every request came from a manual click.
If the error appeared during a purchase or form submission, ask the owner to confirm whether the action was received. A blocked response and an unsuccessful submission are not always the same observation, so repeatedly submitting important information can create confusion.
Find the request pattern behind the rule
Record the counting rule: matching path, counting criteria, threshold, period and action. Then list the calls made by one ordinary use of the feature. A live search might issue multiple requests while a user types; whether those belong in the same rule as login attempts is a scope question for the maintainer.
As the site owner, review the rate-limiting configuration that covers the affected path. Note its matching condition, counting criteria, threshold, time period, and action. Compare those settings with the visitor’s workflow and available request evidence.
For example, a live search feature can make a request as someone types. A rule intended for repeated login attempts may behave poorly if its condition also covers that search endpoint. The appropriate review concerns the rule’s scope and the feature’s request pattern, rather than disabling rate limits everywhere.
Check whether an integration or background script contributes to the same activity. A visitor’s visible action may be only the start of several application requests. The developer can help explain how many requests the feature is meant to make.
Adjust the rule to the intended workload
Use measured legitimate activity to select a focused adjustment and preserve the original configuration. A larger threshold alone may leave a wrongly scoped condition in place. Verify the intended workflow and review the unwanted traffic the rule was designed to handle.
Cloudflare recommends reviewing the configured thresholds and time period. A very short interval can react strongly to a normal burst of requests. Its support documentation suggests considering a longer interval when a rule blocks within an especially short period.
There is no single threshold that fits every WordPress feature. A login endpoint, public search, and automated integration have different needs. Use measured examples of legitimate activity to decide whether the condition, counting behavior, or threshold deserves adjustment.
Keep a copy of the original configuration and make a narrow change. If an exception is needed, the administrator should understand which requests it covers and how long it remains appropriate. A broad allowance can remove useful protection beyond the feature being repaired.
Verify recovery without creating another burst
After the adjustment, test the ordinary workflow at a realistic pace. Include the sequence that previously triggered the error, but do not turn verification into a rapid stream of requests that bears little resemblance to normal use.
Review the corresponding request evidence and confirm that the intended feature completes. Opening the first page successfully does not verify the later search or submission that caused the block.
If unwanted traffic was the reason for the rule, check with the administrator that the revised configuration still serves that purpose. A useful repair improves legitimate access while retaining a clear, documented boundary for excessive activity.
Cloudflare also documents another 1015 message, “Unable to purge,” in the context of cache purging. If that is the complete message you see in a management operation, keep that context separate from a visitor rate-limit page and follow the cache-purge support guidance.
For a continuing visitor block, provide the owner or administrator with the affected path, workflow, error time, and sanitized request evidence. The site owner sets the visitor rate-limiting rules, so this review belongs with the site rather than an assumption that Cloudflare can independently allow every visitor.
Reference: Cloudflare error 1015 documentation.
Confirm the complete workflow at a normal pace
Test the sequence that failed, including the search or submission after the first page loads. Compare the relevant request evidence and intended confirmation. If the failed action was important, verify its status before submitting again. Keep the final rule rationale with the operational notes.