Cloudflare WAF can block malicious traffic, but the real value comes from knowing exactly what it stopped, why it acted, and whether any legitimate requests were affected.
This guide explains how to check results in Cloudflare WAF using the dashboards, logs, and rule-level details that matter most.
What Cloudflare WAF results actually show
When people ask how to check results in Cloudflare WAF, they usually want to confirm one of three things: whether a rule matched, what action Cloudflare took, and whether that action was correct.
Cloudflare’s WAF visibility comes from the Security dashboard, request analytics, firewall event data, and log delivery tools such as Logpush.
Cloudflare WAF results may include managed rules, custom rules, bot-related detections, rate limiting, and other security products depending on your plan and configuration.
The exact fields you see can vary, but the core idea is consistent: find the request, inspect the matched rule, and verify the action.
Start with Security Events in the Cloudflare dashboard
The fastest way to check WAF results is the Security Events view in the Cloudflare dashboard.
This interface shows individual requests that triggered security logic, including the rule or expression that matched and the action applied.
How to open Security Events
- Sign in to the Cloudflare dashboard.
- Select the relevant website or zone.
- Go to Security or Security Center, then open Events.
- Filter by time range, action, rule type, country, IP, hostname, or URI path.
Once you narrow the data, click an event to see details such as the client IP, user agent, request path, matched rule, action, and confidence or threat metadata where available.
What to look for in each event
- Action: Block, challenge, managed challenge, log, bypass, or allow.
- Rule source: Managed WAF rule, custom rule, rate limit, or another security feature.
- Matched expression: The condition that triggered the response.
- Ray ID: Useful for correlating the request across logs and support cases.
- Request metadata: IP, country, ASN, hostname, method, path, and user agent.
If you are testing a new rule, trigger it from a controlled client and immediately search for that request in Security Events.
This is the quickest way to validate whether Cloudflare is evaluating the rule as expected.
Use Cloudflare Analytics for trend-level validation
Security Events are best for single-request inspection, while Analytics helps you understand patterns.
If you want to know whether a WAF rule is reducing attack traffic, check the overall volume of blocked or challenged requests over time.
In Cloudflare’s analytics views, look for changes in:
- Total requests
- Blocked requests
- Challenged requests
- Requests by country or ASN
- Requests to specific paths or hosts
This is especially useful after enabling a new managed rule or deploying a custom rule.
A legitimate spike in blocks can indicate a false positive, while a drop in malicious requests suggests the rule is working.
How to confirm a rule is causing the trend
Trend charts alone do not prove which rule fired.
Use them to spot a shift, then return to Security Events and filter by the same time window.
Matching the two views gives you both statistical and request-level confirmation.
Check WAF results with Logpush and log fields
For teams that need deeper visibility, Cloudflare Logpush is the most reliable way to export WAF result data into a SIEM, data warehouse, or observability platform.
This is the preferred approach when you need long-term retention, centralized monitoring, or advanced filtering.
Depending on your setup, exported logs can include fields such as:
- Action: The response taken by Cloudflare
- Rule ID: The specific rule that matched
- Rule message: Human-readable description of the trigger
- Source: Whether the event came from WAF, custom rules, or another security layer
- Client IP and ASN: Source network information
- Edge response details: Helpful for troubleshooting user impact
Logpush is useful when you want to answer questions such as: Which WAF rule blocked the most traffic last week?
Which customer IPs were challenged?
Did a deployment increase false positives on a specific endpoint?
Inspect rule definitions before judging the result
A WAF event is only useful if you can connect it to the rule definition behind it.
If a request was blocked, review the rule expression, managed rule group, or exception logic that produced the action.
For custom rules
Open the custom rule in the dashboard and inspect the expression.
Confirm that the match conditions are precise enough for your target traffic.
Common issues include overly broad path matches, weak header conditions, or missing exclusions for trusted clients.
For managed rules
Managed WAF rules are maintained by Cloudflare and often grouped by threat category.
If a managed rule causes a false positive, check whether you can:
- Create a targeted exception
- Adjust the rule sensitivity or phase behavior
- Use a skip or bypass rule for a specific path, IP, or user agent
Rule metadata and descriptions help you understand whether the event was expected or if you need to tune the policy.
How to verify a specific request was handled correctly
If you are troubleshooting one request, use the Ray ID from the browser error page, origin logs, or Cloudflare event details.
Then search for that Ray ID in Security Events or in your exported logs.
A practical validation workflow looks like this:
- Capture the request details: time, URL, IP, and Ray ID.
- Search Security Events for that exact timeframe.
- Confirm the matched rule and action.
- Review whether the action aligned with your security policy.
- Adjust the rule if the request was a false positive or missed attack traffic.
This method is especially effective when testing login pages, checkout flows, API endpoints, and admin paths, where a single false block can affect real users.
Common reasons WAF results look confusing
Cloudflare WAF data can be misleading if you do not account for related security features or caching behavior.
A request might be challenged by bot protections, blocked by a firewall rule, or rate limited instead of matching the WAF rule you expected.
- Multiple products are active: Bot Management, Rate Limiting, and firewall rules can all affect the same request.
- Different phases apply: A request may pass one rule and fail another later in the processing chain.
- Sampling or retention limits: Some views may not show every historical request.
- Edge and origin differences: Cloudflare sees the request before your origin server does, so origin logs may not match blocked traffic.
If the result seems inconsistent, compare the dashboard event, exported log entry, and the request path in your origin application logs if the request reached the server at all.
Best practices for reliable WAF result checking
To make Cloudflare WAF verification repeatable, use a consistent process every time you deploy or tune a rule.
- Test in a staging or low-risk environment first.
- Record the exact rule name, ID, and expression.
- Use a fixed time window when reviewing results.
- Correlate Security Events with Logpush data for accuracy.
- Separate legitimate user traffic from test traffic with tags, headers, or known IPs.
- Review both blocks and challenges, not just outright denies.
Teams running production applications should also establish a baseline for normal traffic so that any sudden change in WAF results stands out quickly.
When to use Cloudflare support or documentation
If you cannot find a matching event, the rule appears to be firing unexpectedly, or the dashboard data does not align with your logs, consult Cloudflare’s documentation for the specific product you are using.
Cloudflare support can also help when you provide a Ray ID, exact timestamp, zone name, and a clear description of the expected versus actual behavior.
For most administrators, the answer to how to check results in Cloudflare WAF is a combination of three views: Security Events for request-level detail, Analytics for trends, and Logpush for durable, searchable records.
Using all three together gives you the clearest picture of what Cloudflare protected, what it allowed, and where your rules may need tuning.