Skip to main content
Every evaluation of an alert writes exactly one event, whether or not it breached. The event stream is the alert’s history: what the metric was each time it was checked, when it fired, and which runs it spawned.

​
Statuses

An error event still advances the alert’s window, so a broken query doesn’t pile up a backlog to re-evaluate once it’s fixed.

​
What an event carries

Alongside status, value, and errorMessage, each event records the window it judged (windowStartedAt / windowEndedAt) and runUuids — one run per action fired, empty unless the event is unhealthy. An event also snapshots the alert as it was evaluated: its scope, threshold, and actions are copied onto the event rather than read back from the live alert. Editing an alert’s threshold, or deleting the alert entirely, therefore doesn’t rewrite the meaning of its past events — a firing from last week still shows the threshold it actually breached.

​
Read the history

In the web app, open an alert and switch to the Events tab. Events are listed newest first with their status, computed value, and window, filterable by status; expanding a firing lists the runs it spawned so you can jump straight into what the alert set off.
A run of healthy events with value: null means there was nothing to judge: the scope matched no spans, or — for errorRate and duration — none that had finished yet. That is usually a scope that is too narrow, or a workflow that has stopped running, which a count / lte alert would catch as a breach. See the dead-man’s switch note in Overview.