Security Events

The Security Events page shows you exactly what Cloudflare’s firewall is doing on your zones — every blocked request, every challenged visitor, every rule that fired — without leaving WP admin. It’s how you confirm your WAF rules are working, find IPs to add to your block list, and spot false positives that need tuning.

⚠️ Pro plan required. This feature uses Cloudflare’s firewallEventsAdaptive GraphQL dataset, which is only available on Cloudflare Pro plans or higher. Free zones do not have access to firewall event logs via the API. If a zone is on the Free plan, the Security Events page will display an upgrade notice instead of events. You can still view firewall events for Free zones manually inside the Cloudflare dashboard at Security → Events — this restriction is on Cloudflare’s side, not the plugin’s.

If you don’t have any Pro zones, you can skip this page and rely on the WAF Rules Reference and IP Access Rules pages instead.

Opening the page#

In WP admin, go to WAF Manager → Security Events. The page is laid out as:

• A zone selector at the top — pick which zone you want to inspect
• A time range selector — last 1 hour, 6 hours, 24 hours (default), 3 days, or 7 days
• A limit selector — 50, 100 (default), 200, or 500 events to fetch
• A Load Events button
• After loading: filter tabs by action, a summary, and a table of events

The Load Events button stays disabled until you pick a zone. Once you do, click it and the events load in a second or two.

What you’ll see#

After loading, the table shows one row per firewall event with these columns:

• Time — when the event happened, in your local timezone
• Action — what Cloudflare did (Block, Managed Challenge, JS Challenge, Challenge, Allow, or Log) with a colour-coded badge
• IP Address — the visitor’s IP. This is the column you’ll be copying from when you want to add a rule to IP Access Rules.
• Method — HTTP method (GET, POST, etc.)
• Path — the URL path the visitor tried to hit
• Rule / Source — which rule fired. Rules deployed by this plugin show up tagged [CF WAF] so you can tell them apart from managed rules and Cloudflare’s own protections.
• User Agent — the visitor’s user-agent string
• Ray ID — Cloudflare’s unique request identifier, useful if you ever need to ask Cloudflare support about a specific event

Filtering by action#

Once events are loaded, a row of filter tabs appears above the table:

• All — everything
• 🚫 Block — requests that were dropped
• ⚠️ Managed Challenge — visitors shown a managed challenge
• 🔒 JS Challenge — visitors given a JavaScript challenge
• 🟡 Challenge — interactive challenge events
• ✅ Allow — requests that were explicitly allowed (e.g. by Rule 1’s Skip action or an IP Access Rule whitelist)
• 📋 Log — events from rules in log-only mode

The filters are client-side, so switching between them is instant — no need to reload from Cloudflare.

How to actually use this page#

A few practical workflows:

Verify your rules are working#

Right after deploying WAF rules to a new zone, come here and load the last hour. You should see Block events from Rules 2 and 3 catching scrapers and scanners, and Managed Challenge events from Rules 4 and 5 catching VPN and cloud-provider traffic. If you see nothing, either your zone has very little traffic, or the rules didn’t deploy correctly — go to the View Zone Rules tab on the main dashboard to confirm.

Find brute-force attackers to block#

Switch to the Block filter and look for IPs that appear repeatedly in a short window. An IP that’s tried wp-login.php fifty times in the last hour is a great candidate to add to IP Access Rules with the Block action. You’re upgrading Cloudflare’s response from “challenge each request” to “drop everything from this IP for as long as the rule exists.”

Spot false positives#

Switch to Block or Managed Challenge and scan the User Agent and Path columns. If you see something legitimate being caught — your own backup plugin, a service you actually use, your monitoring agent — that’s a false positive. Note which rule fired (the Rule / Source column), then go back to the WAF Rules Reference and add that service to Rule 1’s whitelist, then redeploy.

Debug a “why am I being blocked” report#

When a user reports they can’t access your site, ask them for their IP and the time it happened. Load events for the affected zone covering that time window, find the matching row, and you’ll see exactly which rule fired and why. From there you can either whitelist them in IP Access Rules, or adjust the rule that caught them.

Investigate an attack#

After a noticeable spike in traffic or a security incident, load 7 days of events at the 500-event limit and switch through the filters. The summary line above the table shows counts per action, giving you a quick sense of the scale.

Time range vs limit#

These two settings interact in a way worth understanding:

• Time range controls how far back Cloudflare searches.
• Limit controls how many events the API returns from that range.

If you ask for the last 7 days with a limit of 100, you’ll get the most recent 100 events from those 7 days — which on a busy site might only cover the last few hours. If you want a representative view of a long time window, increase the limit. If you want every event in a small window, lower the time range.

For day-to-day monitoring, the defaults (24 hours, 100 events) are fine. Bump up to 500 when you’re actively investigating something.