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