There is a common assumption that enabling WAF is a binary decision: it's blocking or it's not. Teams that start from this point activate the managed rulesets in Block mode directly in production, assume that the rules are conservative enough, and then discover that the contract upload form has stopped working, that the integration with payment gateway is returning 403, and that the support team is receiving complaints from customers who are unable to log in. The WAF wasn't wrong — but it also didn't know the application.
What Log mode does and why it exists
Cloudflare WAF has three possible actions for each rule: Block, which returns 403 and terminates the request; Challenge, which presents a challenge to the customer; and Log, which records the occurrence without interfering with the flow. Log mode is the only one that allows you to observe the behavior of rules against real traffic without consequences for users.
When a ruleset is configured with a Log action, all rules fire normally — evaluate headers, URI, body, query string — but instead of blocking, they just log the event. Firewall Events in the Cloudflare dashboard captures each trigger: the originating IP, the full URI, the specific rule ID, and the exact content that caused the match. The request reaches the origin server intact. The user doesn't notice anything.
The deployment sequence that prevents incidents
The process begins by enabling all managed rulesets with the action set to Log. The OWASP paranoia level should be set to 1 from the beginning: this level captures the most obvious attack patterns with the lowest volume of false positives. Going up to level 2 or 3 on the first activation almost guarantees excessive noise that makes it difficult to distinguish real attacks from legitimate, malformatted traffic.
With the rulesets in Log, the Firewall Events dashboard must be reviewed daily. The goal is to identify rules that fire consistently on legitimate requests — the same URI, the same request pattern, the same rule. An isolated shot may be noise; the same trigger on thousands of requests from real users is a false positive that will block traffic when the action changes to Block.
When a false positive is identified, the response is to create a Skip rule: a firewall rule that instructs the WAF to ignore rulesets or specific rules when criteria such as URI and HTTP method match. An endpoint /api/upload that triggers rule 100035 because it accepts files with a .php extension in its name receives a Skip rule that excludes that path from inspection by that rule. The exclusion is surgical: all other traffic continues to be evaluated.
After one to two weeks with the rulesets in Log, false positives handled with Skip rules, and no new triggers on legitimate traffic, the action changes to Block. The criterion is stability, not elapsed time.
Reading Firewall Events accurately
The Firewall Events dashboard shows each event with enough detail to make a decision. In addition to the IP and URI, the event shows the Rule ID that fired — an identifier such as 949110 or 100035 consultable in the Cloudflare documentation — and the matched data, the specific part of the request that caused the match.
This matched data field transforms the investigation from a false positive of speculation into a concrete diagnosis. If rule 100035 fired on POST /api/upload and the matched data shows filename=relatorio.php, it is clear that the rule reacts to the file name, not to malicious content in the body. The resulting Skip rule is precise: it ignores rule 100035 for that path only. Any other endpoint that receives a genuinely suspicious .php continues to be evaluated.
Notification alerts for new WAF events close the loop of continuous detection. When Cloudflare adds a new signature to a circulating CVE, the alert notifies the team — and Firewall Events shows whether the new rule is touching legitimate traffic before it's too late.
WAF Analytics and SIEM integration
For teams with established security operations, Firewall Events data can be exported via Logpush. Logpush sends WAF events to R2, S3, Datadog or Splunk with the full set of fields: timestamp, IP, country, URI, method, Rule ID, action taken and matched data. For a team with an active SOC, this data feeds correlations that the Cloudflare dashboard does not: attack pattern distributed by multiple IPs against the same endpoint over the course of hours, payload variations testing which rule can be circumvented.
WAF Analytics aggregates these events into a time series within Cloudflare. When the action changes from Log to Block, an unexpected increase in 403 responses in normal traffic indicates a false positive that escaped the observation phase — and the Rule ID in the event tells you exactly what to handle.
Building operational habit
WAF is not a one-time configuration. Applications change: new endpoints are added, third-party integrations introduce request patterns that WAF has never seen, and Cloudflare updates managed rulesets regularly.
What works is assigning explicit responsibility: someone on the platform or security team reviews Firewall Events weekly. The review looks for new patterns — rules triggering in high volume that didn't appear before, a spike in lockdowns at peak times. When a new endpoint goes into production, the observation sequence starts again for that path: Log first, Skip rules for false positives, Block later.
When a false positive appears in production — a user reports an unexpected 403 — Rule ID in Firewall Events tells you exactly what's happening. The correct process is to have the Rule ID in hand in less than two minutes, not to find out what was blocking it after support has already received fifty complaints.
Also read
- Cloudflare Workers in production: what changes after hello world
- What still goes through WAF: bypass techniques and how to mitigate
- Managed rules vs custom rules in WAF: when to write your own
- Workers: debugging, logs and Workers Tail — observability at the edge without a log server
- Cloudflare Load Balancing and Geo Steering: when DNS becomes an intelligent traffic layer
- DNS proxied vs DNS only: what changes and when each mode makes sense