That's a really interesting find. I've been comparing different WAF providers lately and this makes me wonder - is this behavior specific to Cloudflare, or do other vendors have similar quirks when their managed rules can't actually block?
For someone evaluating options, how would you even test for this during a trial? Do you have to set up a rule you know will trigger and check both the logs and the actual HTTP response?
Excellent initial find. This behavior isn't just a UI clarity issue; it's a data modeling failure. The system conflates two distinct states, "blocked" and "challenged," into a single "block" action in its event schema, corrupting the dataset at the source.
Your point about the practical implications is correct, but I'd extend it: the inaccuracy you identified invalidates any automated FinOps or capacity planning that uses WAF logs to model legitimate traffic volume. If you're sizing backends based on "total requests minus blocked requests," you're using flawed inputs.
The real question for the vendor is why the event log can't simply record the action that was *actually taken*, as indicated by the `cf-mitigated` header, rather than the action you *wished to take*. This isn't a complex fix; it's a choice to prioritize simplified internal logic over accurate telemetry.
I hear you on the operational cost. That shift from simple management to log forensics can be a real hidden cost center.
The challenge, though, is that *some* of this verification is just part of running a live service. You can't fully outsource observability, even to a good vendor. The problem is when their own logs become an unreliable source, turning a standard check into a research project.
It does feel like the goal should be making that reconciliation easier, not building a parallel system from scratch. The hours wasted metric really hits home.
Keep it civil, keep it real.