How to check Cloudflare firewall events
Cloudflare firewall events show which requests were blocked, challenged, logged, or allowed by your security rules.
If you know where to look in the Cloudflare dashboard and how to interpret the fields, you can quickly identify attacks, false positives, and rule gaps.
This guide explains how to check Cloudflare firewall events in the dashboard, what each event type means, and how to use the data for troubleshooting and security review.
Where Cloudflare firewall events appear
Cloudflare records firewall activity across several security products, including WAF rules, firewall rules, Bot Management, rate limiting, and custom security controls.
The exact location depends on the feature that generated the event, but most investigations start in the Security section of the Cloudflare dashboard.
- Security events: the main view for firewall activity and request outcomes.
- WAF events: useful for managed rules, custom rules, and false-positive analysis.
- Firewall Analytics: useful for trends, traffic patterns, and top sources.
- Logs and exports: helpful when you need to correlate events with application logs or SIEM data.
How to check Cloudflare firewall events in the dashboard
The dashboard is the fastest way to inspect recent events.
Most accounts can view them with a few clicks, as long as the user has the right permissions.
Step 1: Open the correct zone
Sign in to the Cloudflare dashboard and select the domain, also called the zone, you want to review.
Firewall events are zone-specific, so you must be viewing the correct hostname before checking the data.
Step 2: Go to Security or WAF
From the zone overview, open the Security area.
Depending on your plan and dashboard layout, you may see Events, WAF, or Firewall Events directly in the menu.
Step 3: Review recent events
The events table typically shows request outcomes such as block, challenge, skip, log, or allow.
You can inspect individual rows to see the matching rule, source IP, country, user agent, URI path, and timestamp.
Step 4: Filter by rule, action, or time range
Use filters to narrow the data to a specific incident.
Common filters include:
- Time range: last 15 minutes, 24 hours, 7 days, or custom dates.
- Action: block, challenge, managed challenge, log, or allow.
- Source IP: a single IP or subnet involved in suspicious traffic.
- Rule ID or rule name: the exact rule that triggered the event.
- Country or ASN: useful for identifying regional attack patterns.
- Hostname or path: helpful when a single endpoint is being targeted.
What the firewall event fields mean
Cloudflare firewall events are easier to use when you understand the most common fields.
These fields help you decide whether the event is a real attack, a noisy bot, or a legitimate user caught by an overly strict rule.
Action
The action shows what Cloudflare did with the request.
A block means the request was stopped, a challenge or managed challenge means the requester had to prove they were human, and log means the request was recorded without enforcement.
Rule source
This tells you whether the event came from a custom firewall rule, managed WAF rule, rate limiting rule, bot feature, or another security control.
Rule source is one of the fastest ways to identify which security layer needs attention.
Matched data
Depending on the rule type, Cloudflare may show the matched path, header, cookie, query string, or other request details.
This is valuable when you need to understand why traffic was flagged.
Ray ID
The Ray ID is Cloudflare’s request identifier.
Use it to correlate a firewall event with origin logs, support cases, or other Cloudflare security records.
Client details
Many events include the client IP, ASN, country, user agent, and request method.
These details help you recognize scanners, credential-stuffing tools, automated scrapers, and suspicious geographic clusters.
How to investigate suspicious firewall events
When you spot unusual activity, focus on pattern recognition rather than one event alone.
A single block may not matter, but repeated events from the same source or path often reveal the real issue.
- Look for bursts: repeated events in a short period may indicate scanning or brute-force attempts.
- Check the endpoint: login pages, checkout flows, and API endpoints are common targets.
- Review the rule logic: confirm the rule is matching the right condition and not overblocking.
- Compare with origin logs: see whether the same requests reached your server.
- Validate user impact: ask whether legitimate users report login failures, CAPTCHA loops, or broken forms.
If a rule is catching good traffic, you may need to refine the expression, add an exception, or switch from block to challenge.
If the traffic is clearly malicious, use the event details to create stronger rules or rate limits.
How to export or centralize Cloudflare firewall events
For larger environments, dashboard inspection is not enough.
Security teams often export firewall events to a SIEM, data warehouse, or log analysis platform so they can correlate Cloudflare activity with application, identity, and endpoint data.
Common export and integration options include:
- Logpush: streams Cloudflare logs to storage or analytics systems.
- Cloudflare API: useful for automation and custom reporting.
- SIEM tools: such as Splunk, Elastic, and other log platforms.
- Data pipelines: helpful for long-term retention and trend analysis.
Centralization matters because firewall events become more useful when you can join them with authentication failures, 5xx errors, origin latency, or WAF alerts.
How to reduce false positives in firewall events
False positives are common when a site has aggressive bot traffic controls, strict WAF rules, or unusual application behavior.
The goal is to keep protection high while minimizing disruption for real users.
- Use log mode first when testing a new rule.
- Scope rules narrowly to specific paths, methods, or headers.
- Allow known-good traffic from internal services, monitoring tools, or partner IPs.
- Review managed rule sensitivity where your plan supports tuning.
- Test with real user journeys such as login, checkout, and form submission.
When you monitor events after a rule change, compare the number of blocks and challenges before and after the update.
A sudden spike in legitimate traffic being stopped is often the first sign that tuning is needed.
Best practices for reviewing Cloudflare firewall events
To make firewall event reviews more effective, treat them as part of a repeatable security workflow rather than an ad hoc task.
- Check events after rule changes to confirm behavior matches expectations.
- Review high-value endpoints such as login, password reset, and payment pages.
- Track repeat offenders by IP, ASN, or user agent.
- Use time-based baselines to detect new spikes or shifts in traffic.
- Document exceptions so future rule reviews stay consistent.
Cloudflare firewall events are most valuable when they are paired with clear operational context: what changed, who was affected, and whether the rule is protecting the right surface.
Common problems when checking Cloudflare firewall events
Some users struggle to find the right events because of permissions, filtering mistakes, or expectations about data retention.
If the table looks empty, start with these checks.
- Confirm the zone: you may be looking at the wrong domain.
- Check permissions: not every user can view all security data.
- Expand the time range: recent filters can hide relevant events.
- Review the active rule set: the request may have been handled by a different security feature.
- Account for retention limits: older events may not be available in the dashboard.
If the request never appears, remember that not every Cloudflare security decision is surfaced in the same place.
Managed features, worker logic, and origin-side controls can affect what you see.
What to do with firewall event data next
Once you know how to check Cloudflare firewall events, use the data to improve your defenses.
Build a short review routine: identify the top blocked paths, the most common source countries or ASNs, and the rules generating the most challenges.
That pattern shows whether your current policy is stopping real threats or creating unnecessary friction.
For ongoing operations, firewall events should support three goals: faster incident response, better rule tuning, and clearer visibility into attack trends across your web properties.