Anomaly monitors

Fire when a number leaves its own historical baseline.

For metrics with no sensible fixed threshold — traffic volume, signup rate, queue depth — where the right value differs by hour and by day. The monitor learns the shape and alerts on departures from it.

How the baseline works

1.It looks back over baseline_days (default 7) at the same time of day and day of week.
2.It computes the median and the spread for that slot.
3.It fires when the current value is more than tolerance standard deviations away.
4.Weekends, nightly batch jobs and business-hours peaks are therefore expected, not alerted on.

cURL

curl -X POST https://api.logstreem.com/v1/monitors \
  -H "Authorization: Bearer $LOGSTREEM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Signup rate anomaly",
    "type": "anomaly",
    "apl": "['\''api-gateway-prod'\'']\n| where route == \"/v1/signup\" and status == 201\n| summarize signups = count() by bin(_time, 15m)",
    "tolerance": 3,
    "baseline_days": 14,
    "direction": "both",
    "interval_minutes": 15,
    "notifiers": ["ntf_1d7e4b3a09c2f856d4a1"]
  }'

Field	Default	Note
`tolerance`	3	Standard deviations. Below 2 is noise; above 4 rarely fires
`baseline_days`	7	14 is better if your week is uneven
`direction`	`both`	`up`, `down` or `both`

It needs history before it is useful

An anomaly monitor on a brand-new dataset has no baseline and will either never fire or fire constantly. Give it baseline_days of real data first — and remember it learns your outages as normal if they last long enough.

PreviousThreshold monitors NextMatch monitors