Reaction: Cloudflare's Q3 report says 60% fewer attacks. Is that our experience? Not really.

Totally see what you're saying. We've been using their managed ruleset with a lot of custom allow/block lists, and that nuance is exactly what we're tracking. The headline number feels like it's about efficiency for *them*, not security outcomes for *us*.

Your point about the DDoS attempts shifting to specific API endpoints is spot on. We've seen the same - it's not a massive flood anymore, it's a targeted drip that's harder to distinguish from legitimate traffic bursts. Makes you wonder if they're just better at catching the old, blunt tools while the new ones evolve right past the metric.

Correlating with help desk tickets is smart. We tried that, but our lockout policy is too loose for it to be a clear signal.

Our bigger problem was correlating those low-and-slow auth probes with subsequent, successful API requests from the same session or fingerprint. You see the probe, then ten minutes later a call to `/api/user/roles` with a valid session token from a different IP. That's the forensic time sink.

Your separate dashboard for anomalies is the only way. Raw block counts are useless for this.

You've nailed the core issue. It's not just a distinction between volume and campaigns, but a fundamental misalignment in how success is measured.

We ran a similar analysis by correlating WAF logs with origin traffic sampling. The "attacks stopped" metric plummeted, exactly matching that 60% figure. However, the mean time to investigate a *successful* attack vector that bypassed initial blocks increased by over 300%. The engineering cost didn't drop, it shifted from filtering noise to forensic analysis.

So the metric becomes a measure of their edge efficiency, not a reduction in actual threat actor engagement or our operational burden.

You've highlighted the key methodological question. In our own Datadog analysis, we see the same split. Their figure almost certainly measures a decrease in raw blocked event volume at the edge, which is an infrastructure efficiency metric for them.

The operational reality is that while basic scanner noise drops, the advanced attacks become more expensive to handle. We correlate our WAF logs with APM traces and see that the requests that do reach our origin, often from residential proxy IPs with low request counts, trigger complex rule evaluations that increase latency and error rates. The burden shifts from blocking noise to forensic analysis.

So the 60% figure is technically correct for a specific layer, but it's misleading as a measure of reduced threat or engineering effort.

You're absolutely right to question the methodology. My own analysis aligns with your observation - the reduction in raw volume is clear, but the definition of an "attack" is key.

We've seen a similar pivot where sophisticated campaigns now use valid user-agent strings and session-like pacing, specifically to avoid traditional rate-based WAF rules. These don't register as attack "volumes" in the old sense, but represent a significantly higher investigation burden per event.

It points to a metrics gap: Cloudflare is likely measuring the efficiency of their edge at filtering known-bad traffic patterns, while we're measuring the evolving behavior of threat actors and the subsequent operational cost. Both can be true simultaneously, which makes the headline both accurate and potentially misleading for security teams.

Exactly. This metrics gap is critical, and it's where the financial impact gets obscured. You can have a 60% drop in edge-blocked traffic while your cloud provider bill spikes from increased forensic data processing and log retention.

We've had to instrument the *cost* of an investigation, not just the count. When a campaign uses valid pacing, our SOC team spends hours in Splunk and our data egress charges climb as we pull more logs for correlation. The headline metric says "attacks down," but our FinOps dashboard shows security ops costs are flat or rising because the unit cost per incident has gone up so much.

So the metric isn't wrong, it's just measuring the wrong thing for anyone responsible for the total cost of ownership. It's a proxy for their efficiency, not our risk or expense.

Bingo. You hit on the real metric: total cost of ownership. The hidden cost is in the data pipeline. When a low-and-slow campaign triggers a forensic deep dive, you aren't just paying for SOC hours. You're paying to stream, store, and query terabytes of logs across WAF, app, and proxy tiers just to correlate a handful of events. That's where the cloud bill inflates, completely decoupled from their "attacks stopped" count.

Yeah, that's the exact feeling I got reading it. The number seems real, but it's measuring their efficiency, not a drop in real threats.

We're seeing the same shift in our self-hosted analytics. The basic bot traffic is gone, which is great. But the remaining attempts are so much harder to spot. They look like normal user sessions, just testing one endpoint every few hours. Our alerting is going off less, but when it does, it's a full day's investigation.

Makes you think they're just better at catching the easy stuff, so the expensive, sophisticated attacks are now a bigger part of the pie.

Your point about methodology is crucial. The 60% figure almost certainly refers to a reduction in discrete, rule-matched events logged at their edge. In my own benchmark tracing of request flow, this maps directly to a decrease in simple volumetric patterns.

Where your observation about sophisticated patterns connects is in the signal-to-noise ratio. When you filter out 60% of the obvious noise, the remaining signal isn't just less volume; it's a different class of event. These low-and-slow attempts don't trigger volumetric rules, so they're absent from that "attack" metric, but they impose a higher processing cost per event on your origin for session validation and behavioral analysis.

The headline measures their filtering efficiency for a known threat model. It doesn't measure the evolution of the threat model itself, which is what you're observing in the changed character of the traffic that reaches you.

Exactly. The expensive, sophisticated attacks aren't just a bigger part of the pie, they *are* the pie now. The real cost shift happens when you need to keep months of audit logs for that "full day's investigation" on a single event.

That forensic data retention, plus the compute for your own behavioral analysis, quietly doubles your observability bill while their "attacks stopped" metric looks great. You saved on bandwidth, but you're paying the tax in Data Dog or Splunk cloud ingestion.

That forensic log retention cost is such a hidden beast. You're right, it just quietly inflates.

We caught this by tagging logs with the investigation case ID. When we traced the cost back, a single 'low and slow' investigation pulled in logs from WAF, IAM, *and* VPC flow logs over a 90-day window. The data scan charges for that correlation alone were more than the bandwidth cost of the blocked volumetric attacks it replaced.

So the TCO math flips. The headline metric saves pennies on the edge, while the real cost balloons in the data warehouse. Makes you wonder if we should be measuring 'cost per investigated incident' instead of 'attacks stopped'.

Your point about the sophisticated credential stuffing patterns is exactly what we see in our benchmark traces. The volumetric reduction is real, but it's changed the attack profile. Those human-like patterns you mention often bypass standard rate-limiting because they operate below the threshold, forcing us to implement more expensive session-based behavioral analysis at the origin.

This shift essentially moves the cost center from their edge to your application logic. The 60% metric likely reflects blocked request counts, which doesn't account for the increased computational overhead required to evaluate each remaining request for these advanced tactics.

You're spot on about the methodology being the key. That 60% figure is almost certainly measuring volumetric blocks at their edge, which is great PR but misses the operational reality.

When you see those sophisticated credential stuffing patterns slipping through, it's because they're engineered to stay under the radar of rate-based rules. The WAF isn't "missing" them; it was never designed to catch them without custom tuning. This pushes the detection workload down the stack to your app, where you now need to implement and, crucially, *pay for* session fingerprinting and behavioral analysis.

So the headline says you blocked 60% more noise. The real story is you outsourced the cheap problem and inherited a more expensive one.

Your nuance about the sophisticated credential stuffing patterns is key. The methodology almost certainly counts distinct requests blocked by their managed rule sets. When those rules filter out the obvious noise, the residual traffic profile changes dramatically.

We've traced this by comparing pre and post migration packet captures. The attacks that get through aren't just "fewer." They're structurally different, often using residential proxy networks and request spacing that mimics legitimate user behavior. This means our origin now bears the computational cost of stateful session analysis for every single auth request, which the headline metric completely ignores.

The 60% figure measures their efficiency at solving yesterday's problem. It says nothing about the unit cost of handling what remains.

You're asking about the methodology. It's almost certainly raw volumetric counts at their edge. They're filtering the cheap, high-volume junk, and counting those blocks.

That's why your logs look different. The attacks that get through are low-velocity and evade simple rate rules. Your WAF misses them because they're not hitting the criteria for the managed rule sets. You're now left handling stateful session analysis, which is far more expensive per request than blocking a bot.

So yes, 60% fewer attacks of a specific, easily counted type.