Anomaly detection / alerting
An automatic warning when a metric moves outside its expected range, so a real spike or drop is noticed before the next dashboard check.
See it
What it is
Anomaly detection compares each new metric value with an expected range and flags values outside it. The expectation may be a fixed threshold, a rolling baseline, or a seasonal baseline built from the same hour or weekday in earlier weeks. Alerting is the delivery layer that turns the flag into a message somebody can act on.
Reach for it when waiting for the next dashboard review would be too slow: checkout failures, traffic collapses, signup spikes, or a sudden change in a guardrail metric. A rolling median plus median absolute deviation is a useful robust baseline because one wild point does not drag the expectation toward itself. That pairing has a name and a published threshold: the modified z-score, which Iglewicz and Hoaglin suggest flagging above 3.5.
Gotcha: unusual does not mean bad, and it never explains the cause. A launch, holiday, campaign, stale pipeline, or tiny denominator can all trigger a mathematically valid but useless alert. Require meaningful volume, wait for repeated breaches, deduplicate messages, and send a recovery notification so the channel does not become an alarm graveyard.
Ask AI for it
Build a scheduled anomaly detector for [metric] using a rolling median and median absolute deviation over the previous eight matching weekdays. Calculate the modified z-score, require at least [minimum volume], and open an alert only after two consecutive points exceed an absolute score of 3.5. Suppress checks when the source freshness SLA is breached. Send one deduplicated Slack webhook containing the observed value, expected range, dashboard link, and latest deploy timestamp, then send one recovery message after two normal points and enforce a six-hour cooldown.