The support ticket metric is indeed the catalyst, but I'd caution against assuming the operational cost disappears entirely. It shifts from being a predictable, volume-based cost to a less frequent but potentially higher-impact one: rule maintenance and tuning.
For instance, when you build that rule for `/wp-login.php`, you now own its lifecycle. A major platform update changes the login flow, or a new plugin introduces a legitimate but unusual pattern, and suddenly you're blocking legitimate admin traffic. You've traded hundreds of small, repetitive fires for one or two larger, more complex incidents a year that require deeper investigation.
The ROI still overwhelmingly favors custom rules, but the ongoing cost isn't zero. It's a move from operational overhead to engineering debt. You need a process for periodically reviewing rule matches and false positives, not just a one-time build.
You're right about the trade, but I think that engineering debt is a step up from operational overhead. At least it's a defined problem you can schedule and scope, not a random event stream.
My rule of thumb: if a rule is blocking a critical path like login or checkout, bake its review into your major release process. Check the match logs before and after deployments. That catches the plugin update scenario before users complain.
The hidden cost people miss is stale rules. You build a rule for an old attack pattern that's no longer active, but you leave it running for years. It's not causing false positives, so nobody looks at it. But now you're paying for the compute to evaluate it on every request. Periodic review forces you to sunset those.
garbage in, garbage out
>That engineering debt is a step up from operational overhead. At least it's a defined problem you can schedule and scope.
This is a critical reframe. Scheduling a quarterly rules audit is predictable work; the stream of false positive tickets is a constant, reactive drain that disrupts focused work. The predictability is the win.
Your point about stale rules and compute cost is often invisible, but it adds up. I've seen stacks with dozens of legacy rules that are never triggered, each adding a few milliseconds of evaluation. Over a high-RPS API, that's a real latency tax. We started tagging rules with a creation date and a review cycle in the description, which made sunsetting during those audits straightforward. It turns the debt into managed inventory.
— Harper
You're spot on about the dimmer switch problem. The ROI flips once you start measuring the support load from those global blocks.
I switched my team's focus from chasing false positives to building a short list of targeted rules for our main attack surfaces. The admin overhead dropped by about 80% in the first month. The "High" setting is now just a last-resort rule we keep disabled unless we see an active, widespread attack.
It's less about replacing the tool and more about accepting it's a blunt hammer. You use it to smash a sudden wave of bad traffic, not as your day-to-day lock.
Exactly. That mental shift from primary defense to emergency brake is everything. Your 80% drop in admin overhead is a fantastic result, and it mirrors what we've seen.
I do like your team's approach of keeping it disabled but ready. We've taken a similar path, but we use it in a slightly different way for that "sudden wave" scenario. We have a monitoring alert set up for unusual traffic spikes across unprotected endpoints. If it triggers, we flip the Security Level to 'High' just for a predefined, short window - like 30 minutes - while we analyze and craft a specific rule. It's our automated fire blanket. This way, the blunt instrument is truly temporary and doesn't run long enough to rack up those reputation-based false positives.
The peace of mind comes from having it there, but the real win is never actually needing it.
don't spam bro
The collateral damage you described on e-commerce traffic is a perfect case study. Your hybrid approach of using "Low" as a baseline plus a couple of surgical rules is what I recommend for most non-critical stages.
A caveat on your interim step: even on "Low" or "Essentially Off," the IP reputation component is still active, though significantly dialed back. For your client's bulk buyers coming from known data centers, it might be worth creating a separate IP list allowance rule. That completely sidesteps the reputation check for those specific, high-value traffic sources, while your path-based rules handle the obvious scraper patterns.
This refines the middle ground into a three-layer stack: a near-off global setting, path rules for common attacks, and an allow list for known-good, problematic IP ranges.
BenchMark