Alert fatigue is a detection engineering problem

Tuning is usually treated as clean-up work that happens after a detection ships, handed to whoever is on shift when the false positives pile up. Treating it instead as part of the detection's actual lifecycle — with an owner, a review cadence, and a precision target set before the rule ever goes live — changes how a SOC triages day to day.

The scenario that makes this concrete

A detection for suspicious PowerShell encoded commands ships with good intentions and a broad net. Within a week it's firing 200 times a day, 195 of which are a legitimate configuration management tool that happens to use encoded commands for argument passing. Analysts learn, correctly, that this alert is almost never worth opening. Three months later, an actual encoded-command attack sails through, because the alert had long since become background noise that nobody trusted enough to act on.

That outcome isn't an analyst failure. It's the predictable result of shipping a detection with no stated precision target and no plan to revisit it. A rule with no documented expected false-positive rate has no way to fail a review, because there was never a bar to clear in the first place.

A lifecycle, not a launch

Every detection worth keeping should move through the same five stages, and none of them are optional:

• Design — map the detection to a specific technique and sub-technique, and write down what "acceptable precision" means for it before writing any logic.
• Validate — test against both malicious and benign samples before deployment, not after the first complaint.
• Deploy — ship with an assigned owner and a 30/60/90-day check-in already on the calendar.
• Tune — treat the scheduled check-in as real work, not something that only happens when the noise becomes unbearable.
• Retire — a detection that can't be tuned to an acceptable precision after two review cycles should be turned off, not left running as ambient noise.

That last stage is the one most SOCs skip, and it's arguably the most important one. A detection that nobody trusts is worse than no detection at all, because it consumes analyst attention while providing negative signal value.

Metrics that actually predict fatigue

Alert volume alone is a bad proxy for fatigue — a high-volume, high-precision detection is fine, and a low-volume, low-precision one can still poison trust. The combination worth tracking per detection is:

• Precision — true positives divided by total alerts, reviewed on the same cadence as the tuning check-in.
• Mean time to triage — if analysts are taking longer to close alerts from a given rule, that's often an early signal the rule lacks the context needed for a fast decision, not that analysts are slower.
• Dismissal rate without investigation — alerts closed in under a few seconds are a strong indicator the rule has already lost analyst trust, whatever the "official" precision number says.

Getting analyst buy-in on the numbers

None of this works if tuning decisions get made without the people triaging the alerts. Analysts develop an intuition for which rules are worth their attention long before that shows up in a metrics dashboard, and that intuition is a leading indicator worth capturing formally — a two-question survey at each review ("do you trust this alert" and "what's usually wrong when it fires") often surfaces tuning opportunities faster than log analysis alone.