Skip to main content
A trigger runs work. An alert watches and tells you. Both are configured per namespace and both can end in a Slack message, which is why they get confused.

Which one do I want

The short test: if the outcome is work that happened, you want a trigger. If the outcome is someone finding out, you want an alert.

Triggers

A trigger is a schedule plus an action.
cURL
A trigger’s output is its run history. Read it to see what ran and what failed.

Alerts

An alert is a source plus a condition plus somewhere to send the news. notification_config.channels takes one or more of webhook, slack, and email.
cURL

When a retriever alert is evaluated

execution_mode takes on_ingest, scheduled, or on_demand. on_ingest is what most alerts want. It rides the ingestion pipeline, so the alert is evaluated against data at the moment that data lands. Every retriever alert that is not on_demand is also evaluated every 5 minutes, which is how an alert on data written directly through the API fires. To evaluate an alert on a schedule of your own, create a trigger whose action is alert_evaluation. While that trigger is active, the alert is evaluated on its schedule in the trigger’s namespace and the 5-minute evaluation leaves it alone there. Pause or delete the trigger to hand it back.
cURL
A scheduled evaluation behaves like any other: the alert notifies when its condition starts to hold, stays quiet while it keeps holding unless renotify_interval_seconds is set, and respects cooldown_seconds. Each run appears in the trigger’s run history. on_demand alerts are never evaluated automatically; call them yourself.

Webhooks

Where an alert’s webhook channel delivers.

Change feed

Reading what changed, rather than being told.