cx-alert-monitor-speclisted

# Alert and monitor specs The pattern is always the same. Someone runs a search — every conversation where a customer threatened to go to the regulator, every ticket about a failing payment partner — finds it valuable, and asks to be told whenever it happens again. Almost every alert built this way is muted or ignored within two weeks, for one reason: **it fires more often than anyone budgeted for, and nobody measured that before shipping it.** The good news is that you already have the data to predict it. The historical sweep that motivated the alert *is* the volume forecast. ## Step 1: forecast the alert volume before building anything Run the detection rule over a historical window and count how often it would have fired, per day and per week. Then check that number against the reality of who is meant to act on it. Rough guidance, and worth stating to the user explicitly: | Firing rate | Viable if | | --- | --- | | A few per week | A named person reviews each one. This is the sweet spot. | | A few per day | There is a rota and a triage step. | | Tens per day | Only as a queue or a dashboard, never as a notification. | | Hundreds per day | Not an alert. It is a metric — chart it. | **If the forecast is above the budget, fix the rule or change the delivery. Do not ship it and hope.** An alert channel that people mute is worse than no alert, because everyone believes the risk is covered. State the forecast in the spec. It is the number that makes the alert's fate pre