Which Cloudflare rule is blocking my visitors?

Updated 2026-10-16

Short answer: Cloudflare's Security Events log records every block and challenge with the security product and the rule that made it. Filter it to the pages real people use, not the ones scanners probe, and look at which rule fires most. That rule is almost always the one locking out your visitors.

How to check it yourself

  1. In the Cloudflare dashboard, open your domain, then Security, then Events.
  2. Set the time range to when visitors reported the problem.
  3. Look at the action (Block, Managed Challenge), the service and the rule for each event.
  4. Ignore requests for paths like /wp-login.php, /.env or /xmlrpc.php on a site that doesn't use them: that's scanners. Blocks on your real pages (/, /contact, /shop) are the ones that hit people.
  5. Open one of those events to see the exact rule, then adjust it or skip it for the paths that need it.

What Preventionlabs shows

With a read-only Cloudflare token, the report lists what Cloudflare blocked in the last 24 hours in Cloudflare's own words: the security product and rule behind each block, and the addresses blocked most. For example, from a real report: "Managed Rules 32 ('Wordpress - Remote Code Execution - CVE:CVE-2026-63030' 18, 'React - RCE - CVE:CVE-2025-55182' 12 ...). Most blocked addresses: / (29), /index.php (1), /wp-config.php.bak (1)." It separates blocks on real pages, which may be real visitors or search engines, from scanner probes, and flags when blocks are spiking. Visitor IP addresses are not read. On another real site, a custom rule named "Block AI bots on ad pages" blocked 23 requests in a day, 14 of them for /sitemap.xml: a rule meant for one thing was quietly turning away search engines.

Price

First report free, no card needed. Then A$50 a month, up to 10 domains.

Run your first report free