alert-tuninglisted

# Alert Tuning > **Discipline balance**: too little tuning = analyst fatigue + missed real alerts in the flood. Too much tuning = silent failure where your rules detect nothing but no one notices. Suppressions always with rule-id + reason + expiry, never wildcard-permanent. Periodic review required. ## When to use A SOC that does not tune drowns in alerts. A SOC that tunes too aggressively misses incidents. This skill is the discipline between those two. Triggers on: - A question like "we have 5000 alerts per day, how do we get fewer", "how do we suppress this rule cleanly", "rule X never fires now, is that right", "review our tuning stack". - A baseline measurement before putting a new rule into production (see `detection-engineer` phase 4). - A periodic (quarterly) review cycle of active rules. - A handoff from `detection-engineer` (rule with too high an FP rate needs tuning). - A SOC MTTR measurement where tuning action has been identified as the root cause. ### When NOT (handoff) - Writing a new rule → `detection-engineer`. This skill works on existing rules. - Triage of a specific alert in real time → `log-triage`, `siem-query`. This skill is at rule level, not alert instance. - IOC feed curation → `ioc-hunter`. - Threat hunt to find undetected TTPs → `threat-hunt` (command). - Detection-coverage mapping → `detection-engineer` or DeTT&CT. ## Approach Six phases. Phase 1 (volume triage) is always the starting point; phase 5 (lifecycle discipline) is what saves an