Skip to main content
Alerts (Signals) raise instances when entities of interest appear, then notify and let you act. This reference documents the full model. For the user guide, see Signals → Alerts.

The tag-driven model

This is the key concept: an alert triggers on tags, not on a raw metric threshold.
  • The metric → threshold logic lives in tagging rules (a metric condition tags the matching entities).
  • An alert then watches for entities carrying those tags, within a perimeter and at a check level, and notifies.
So “alert me when days-of-stock ≤ 7” is expressed as: a tagging rule that tags low-stock items, plus an alert that watches that tag.

Alert definition

An alerts row has:

The metric catalog

Metrics live in a separate alert_metrics catalog (referenced by tagging-rule metric conditions). Each metric is GLOBAL (shared) or ORG-scoped, has a kind (precomputed_column, aggregation, time_windowed_aggregation, formula, composite), a calculation body, a grain, and an output. The standard metrics:
The catalog attributes (scope, kind, body, grain) are populated at the data-platform/seed level — they are part of the stored metric definition, not the app-side create form (which only sets category, subcategory, metricName, description, selectors).
These metrics are consumed by tagging-rule metric conditions, which is where the operator (incl. percentiles) and threshold are set. Alerts then watch the resulting tags.

Lifecycle

An alert is just active or not (isActive). Each evaluation produces instances with their own lifecycle — see Instances & runs.