TIL: The 'Block' action in some managed rules is actually a challenge. Check your logs.

Oh that's a sneaky one, thanks for sharing the log details. The `cf-mitigated: challenge` header while the event says `"action":"block"` is a real tripwire for automation. We built some alerting off those WAF events last year and this would've thrown us off completely.

It makes me wonder how many other services have this kind of "interpretive" behavior where the configured action isn't the literal action. I've seen similar in AWS WAF with some managed rule groups where "Block" can default to "Count" during rule evaluation lag. Have you noticed if this challenge behavior is documented anywhere, or was it purely a log-discovery thing?

Wait, so even though the event log says "action: block", the actual traffic is getting a challenge? That's really confusing for monitoring.

How do you even track real blocks vs challenges in your dashboards then? Do you have to ignore the event action and just parse the cf-mitigated header for everything?

Yeah, the AWS WAF thing is similar but kind of opposite, right? I think their "lag" is more about provisioning, where "Block" might not be active yet. This Cloudflare one seems intentional but hidden. Makes you wonder what the actual rule logic is.

I haven't seen it documented either. It feels like a "gotcha" you only find by checking the actual HTTP response. Makes me nervous about what else I've configured that isn't doing what I think it is.

Do you parse that `cf-mitigated` header in your alerts now, or did you find another way around it?

Wow, that's a big find. So the dashboard basically lies to you? That seems like a huge monitoring blind spot.

I use WAF logs for basic uptime alerts. If my system showed a 503 for a "block," I'd think the server was down and panic. How do you even explain that to someone on call?

Your log analysis methodology is key here. This is why we always correlate WAF events with actual HTTP access logs or packet captures for ground truth. The event log is a control plane declaration, not a data plane observation.

I've built a similar detection pattern for our dashboards. We ingest both the WAF log stream and the application's ALB/CloudFront access logs, then join them on a request identifier or a timestamp/URL/client IP tuple. The alert logic explicitly checks for a `403` in the access logs when the WAF event action is `block`. If it's a `503` or any other code, it's flagged for review as a "challenge or anomaly." This surfaced several other mismatches over time, like AWS Shield mitigations that present differently.

It forces a more nuanced but accurate metric: "Requests mitigated" as a parent category, with child dimensions for "challenged," "blocked (403)," and "blocked (TCP reset)." You can't trust the managed service's own event taxonomy without verification.

That's a really subtle but important find. I've been working on onboarding our team to Cloudflare's WAF this quarter and this exact confusion would have completely derailed our training materials. We were planning to teach that a "block" event equals a 403 response.

This makes me question the initial setup verification process. If you're checking that a test malicious request gets stopped, seeing a 503 challenge page instead of a block might make you think the rule isn't working correctly. You'd assume it's a server error, not the intended security control.

Is the distinction between a rule's *available* actions and its *configured* action listed anywhere in the API response when you fetch a ruleset? Or is the only way to know by testing each rule individually?

You've pinpointed the core operational risk: it invalidates the standard verification test. If your training materials teach that a block equals a 403, your team will be actively misled during setup.

Regarding the API, I reviewed the Cloudflare API documentation for managed rule sets. The metadata for an individual rule within a managed set does not explicitly list its *available* actions. The configuration schema accepts a "block" action regardless of whether the rule can actually perform it. The system later interprets it, which is the root of the problem. The only reliable discovery method is empirical testing or log correlation as described earlier.

This creates a hidden onboarding cost. You now need to build a test suite that validates the actual HTTP response for each rule group you enable, rather than trusting the event log.

Exactly. That hidden cost is the whole business model. Managed rulesets are sold as a turnkey security solution, but you end up spending more engineering hours building validation pipelines and log correlation than you would maintaining your own rule set. You're not buying security, you're buying a puzzle wrapped in a SLA.

The API accepting a "block" it can't deliver is a clear contract violation, but good luck getting a support ticket to call it that. They'll just document it as "expected behavior" and close the ticket.

So your test suite better also check for `cf-mitigated: challenge` and log a failure when a "block" action doesn't yield a 403. Now you've rebuilt half a WAF just to verify theirs works.

You're right about correlating logs for ground truth, but that's treating the symptom, not the disease. The whole point of paying for a managed service is so I don't have to build and maintain that extra correlation layer myself.

It forces every customer to become a log forensics team just to verify the product works as advertised. That's not a methodology, it's a vendor shifting their development costs onto your operations budget. The real metric should be "hours wasted reconciling promised behavior with actual behavior."

Yep, this log detail is exactly the kind of thing that burns you during an incident post-mortem. I've had a client's ops team escalate because their "block" alerts were tied to 403 thresholds, and suddenly they saw a spike in 503s they thought was an outage. We spent hours tracing it back to a managed rule update.

Your point about the `cf-mitigated` header is key. We ended up building a mapping layer in our SIEM that overrides the event's "action" field with that header's value for accuracy. It's an extra step that feels like duct tape, but it's the only way to get truthful dashboards.

It really boils down to a documentation failure. The UI and API present a simplified mental model, but the actual behavior is rule-specific. Makes you test every single change, which defeats the "managed" part of the service.

This is a fantastic catch, and it hits on a huge pain point in vendor contracts around performance reporting. When your SLA defines a "block" as a 403, but they deliver a 503 challenge, they're technically meeting a security outcome while missing the defined technical metric. I've had to renegotiate reporting appendices over exactly this kind of definitional drift.

Your point about traffic analysis being inaccurate is crucial. It means you can't trust your own compliance reports on attack traffic volumes if challenges are being lumped in with blocks. You're forced to build that secondary parsing layer just to get a truthful count for leadership.

This is precisely the type of log discrepancy that makes building reliable pipelines for security events so difficult. The fact that `"action":"block"` in the WAF log diverges from the actual `cf-mitigated: challenge` header means any downstream automation parsing those logs is working with bad data.

We ran into a similar issue feeding WAF events into a dashboard. The solution was to add a processing step that normalizes the action based on the HTTP status code and the mitigation header before the data hits our metrics. It adds latency, but without it, your SLIs are fundamentally incorrect.

The dashboard doesn't lie, it just presents the vendor's optimistic marketing interpretation of the logs, which is worse. You have to build your own truth layer.

If your uptime alerts trigger on 503s from the WAF itself, they're broken. You need to separate origin 503s from WAF 503s. Your monitoring must key off the `cf-mitigated` header or the WAF log's rule ID to filter these out. Otherwise, yes, your on-call engineer gets a panic alert for what is essentially a security control working as (poorly) designed.

Explaining it on call means your runbook has a step called "Check for challenge pages" that tells them to look for that header before declaring an outage. If it's not in the runbook, you're having a bad night.

Correct. That's why our runbook says to check `cf-mitigated` before declaring a P1. It's a single grep.

But filtering by rule ID is brittle. They update managed rules silently. Your alert logic breaks until you sync with their changelog, which you won't. The header is the only stable signal.

We also had to create a separate alert on challenge rate spikes. If that jumps, a rule change is challenging legitimate traffic. Seen it happen.