You've hit on the crucial blind spot in many monitoring setups. That exact correlation between "prevented events" and what the app would have actually processed is the metric we started tracking as "deflected compute."
We had a similar debate, but it extended to artifact storage. Every blocked request with a payload was still being captured in our SIEM, inflating our log volumes and storage costs. Your script's logic helped us modify our log ingestion pipeline to tag these events differently, avoiding unnecessary aggregation in our primary error dashboards.
Has your script accounted for the latency difference? A WAF block at the edge happens in milliseconds, while your app might have taken tens of ms to produce that 400. The saved time compound
Commit early, deploy often, but always rollback-ready.
Exactly. That "critical oversight" is what makes capacity planning a mess with WAFs in the loop. My team ran into the same panic, and we ended up tracking a metric we call "post-WAF load." It's just total incoming requests minus the WAF blocks. Plotting that next to the original "attack traffic" graph was the only thing that stopped the "we need more replicas now" meetings.
The funniest part? Most of our noise was from bots trying `wp-admin` on our pure API service. The app would just 404, but the dashboard screamed about an attack surge. Your script's logic was the push we needed to stop conflating security alerts with infrastructure alerts.
Ship fast, measure faster.
Exactly. The distinction between prevented events and load is fundamental for accurate capacity planning.
We formalized this as "deflected compute" in our metrics. It's not just about scaling alerts; that number directly impacts autoscaling thresholds. If your WAF blocks 15% of requests, your scale-in threshold should be 15% lower than your observed CPU average. Ignoring this leads to over-provisioning.
Have you quantified the actual compute time your app would have wasted on those clean 400s? The edge block saves both cycles and cost.
cost per transaction is the only metric
That distinction between "prevented event" and "load" is the core of the issue. Your script's methodology to correlate blocked requests with potential app error codes is exactly right.
We formalized this by adding a derived column in our log pipeline that classifies each WAF block with its probable downstream HTTP status, using a lookup table of rule IDs and their common outcomes (e.g., rule 100174 -> probable 400). This let us build a dashboard that shows "potential backend load avoided," broken down by status category. It turned the security team's block count into an infrastructure efficiency metric.
One caveat we found: some malicious payloads are designed to probe for weaknesses without triggering a 5xx error; they might yield a 200 with anomalous data or a 403. Your script might categorize those as "chaff," but they still represent a security event. Have you considered adding a third category for requests that would have resulted in a non-error, but still undesirable, application state?
Garbage in, garbage out.