Admittedly, it is easy to miss since the majority of the page is taken up by empty space and a big red circle. Nonetheless, that tiny string of characters at the bottom is your golden ticket. With it, you can find what Cloudflare rule was tripped to show this page.
Using Security Analytics to trace the block
Once you have the Ray ID from the block page, the next step is to head into the Cloudflare dashboard managing the website. Go to the website and then, on the left, look for Security and then Analytics.
That’s where Cloudflare’s firewall and rule activity is logged. It also has powerful filtering tools to zero in on the offending event. Here’s what you need to do:
Log into the Cloudflare dashboard and select the relevant site.
Go to Security > Analytics in the left-hand menu.
Look for the Suspicious activity section or a list of security events.
Click the Add filter button directly beneath.
Select Ray ID in the first box, equals in the second, and place your Ray ID in the third.
Click Apply.
Once that is done, you’ll see the rule that caused the block page to appear, or as Nathan puts it:
You get that Ray ID and you go to Security > Analytics. Add a filter for Ray ID equals [value], and it'll bring up that one event and show you there what rule triggered the problem.
That’s all you need to do. Now you’ve gone from a frustrating block page to a specific, identifiable event in Cloudflare. From here, you can proceed to the rule itself.
Identifying the offending rule
After you’ve filtered down the relevant event, Cloudflare will show you precisely which rule triggered it. Typically you’ll see the rule name, the rule group (e.g. managed rules, custom rules, rate limiting, etc.), the action taken (e.g. block, challenge), and the request details that matched the rule.
In our viewer’s case it turned out to be the Leaked Credential Check managed rule. They turned each rule off until they found this one. Leaked Credential Check designed to flag login attempts using credentials that have appeared in known data breaches, however it can sometimes fire unexpectedly and block access.
How to resolve the block?
Now that you know which rule caused the block, you have a few options depending on your situation.
Be certain of the cause before taking action. Rules can throw false positives and taking decisive action (such as completely disabling them) could have undesired consequences.
Here’s what you can do to prevent the rule, any rule, from interfering with access to the site. All rules are managed from Security > Security rules.
Deactivate the rule: This is the most straightforward way. If you are certain the rule is only producing false positives, you can disable it entirely.
Create a rule exception: Instead of deactivating the rule, you can configure an exception for a specific IP address, path, or user agent. This leaves the rule active for everyone else.
Adjust the rule action: Instead of blocking, you might change the action to “challenge” or “log only.”
Whichever approach you take, make note of what you changed and why. Cloudflare rules are easy to forget about, and proper documentation of changes will save you a lot of head-scratching down the line.
Getting locked out of a site you manage is never fun, but Cloudflare gives you all the tools and information to investigate quickly and confidently.
The key takeaway is simple: find the Ray ID, filter the security events with it, and adjust the rule as necessary.
This workflow is great when managing client sites as well, as all they need to do is give you the Ray ID from the bottom of the page, and you handle it from there. It shows your clients you are proactive and can swiftly resolve the issue.
If you want to learn more about Cloudflare, how it works, how to set it up, and everything it can do for your website, join us for our livestreams in May:
Cloudflare basics: setup and configuration
Cloudflare advanced: optimization and security
And if you have any questions about Cloudflare in the meantime, agencies, WordPress, or hosting in general, come to our Office Hours where you can get answers live.
FAQ
What do I do if a visitor reports being blocked but I can't reproduce it?
This is one of the trickier scenarios, and it's where asking the visitor for the Ray ID directly becomes essential. When a Cloudflare block page appears, the Ray ID is shown at the bottom. It's unique to that specific request, so the visitor's Ray ID points to their exact blocked event, not a generic version of the issue.
Asking them to screenshot or copy that string before navigating away is the fastest path to a diagnosis. If the block isn't producing a Cloudflare page (for example, if a request is silently failing or returning an error), Cloudflare's Security Analytics still logs all firewall events. You can filter by IP address, path, or time window to find the relevant event even without a Ray ID.
Can Cloudflare rules block the site owner themselves?
Yes, and it happens more often than people expect, particularly after aggressive WAF rule changes or when managing a site from an IP that triggers a geoblocking rule. The important thing to know is that Cloudflare's dashboard is completely separate from the website itself. The dashboard is hosted on Cloudflare's own infrastructure and is never blocked by the rules you configure for your site.
So even if you've locked yourself out of your own website, you can always access the Cloudflare dashboard from any connection to adjust or disable the offending rule.
How long does Cloudflare retain Security Analytics data?
Cloudflare retains Security Analytics data for varying durations depending on the plan tier. On free plans, event logs are typically retained for 24 hours; paid plans extend this to several days or longer. This means that for lower-tier plans, there genuinely is a risk of a Ray ID becoming unsearchable if the investigation is delayed.
For agency owners managing client sites, this is a practical argument for ensuring client sites are on at least a paid Cloudflare tier, both for the longer log retention and for the additional diagnostic tools those plans unlock.
Are there situations where the right response to a false-positive block is to leave the rule active rather than disabling or modifying it?
Yes, and this is worth thinking through carefully before making changes. Some rules that appear to cause false positives are actually catching something real like a credential stuffing attempt, a scanner probing for vulnerabilities, or an unusual request pattern that happens to match legitimate admin activity.
Before disabling a rule, it's worth reviewing the full event details Cloudflare provides: the source IP, the request path, the user agent, and any other context that might clarify whether the block was genuinely unwarranted. If the block was triggered by a known, trusted IP, creating a narrow exception for it is almost always preferable to deactivating the rule entirely. Disabling a managed rule site-wide to fix a single false positive is a common mistake that quietly removes protection for everyone else.
