Match monitors

Fire on any single event matching a filter — no aggregation, no threshold.

Some events are worth a page on their own: a security-relevant action, a payment reconciliation failure, a panic. Match monitors notify on the event itself and include its fields in the notification.

No summarize — the rows are the alert

read top to bottom

1['audit-trail']
2| where action == "role.granted" and ['target.role'] == "admin"
3| project _time, ['actor.email'], ['target.email'], source_ip

cURL

curl -X POST https://api.logstreem.com/v1/monitors \
  -H "Authorization: Bearer $LOGSTREEM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Admin role granted",
    "type": "match",
    "apl": "…the query above…",
    "interval_minutes": 1,
    "max_notifications_per_interval": 10,
    "notifiers": ["ntf_security"]
  }'

Cap the notifications

A match monitor on a filter that suddenly matches thousands of events will send thousands of notifications. max_notifications_per_interval is not optional — set it, and make the filter specific enough that the cap is never the thing saving you.

Good match monitor	Bad match monitor
`action == "role.granted"`	`level == "error"`
`message has "panic:"`	`status >= 400`
`amount > 100000 and status == "failed"`	`service == "checkout"`

PreviousAnomaly monitors NextNotifiers