Creating an alert rule
Go to Alerts and click Create Alert.1
Name the rule
Give it a descriptive name — e.g.
High error rate — support agent or Cost spike — prod.2
Choose a metric
To monitor a custom evaluator score, select your evaluator from the Evaluator dropdown and enter the metric key.
3
Set condition and threshold
Choose an operator (
>, <, >=, <=) and the threshold value.Example: error_rate > 0.05 fires when more than 5% of operations fail.4
Set the evaluation window
The window controls how far back data is aggregated before comparing to your threshold.
5
Add notification channels
Add one or more channels. You can mix channel types on a single rule.Email — enter one or more addresses (comma-separated). Receives an HTML alert with metric, current value, threshold, and a direct link to the dashboard.Slack — paste your Slack incoming webhook URL. Alert arrives as a colour-coded message (red = critical, orange = warning, blue = info).PagerDuty — paste your Events API v2 integration key. Alert triggers an incident with severity mapped to the configured level.OpsGenie — paste your OpsGenie API key. Creates an alert with priority P1/P2/P3.Discord — paste your Discord webhook URL. Alert arrives as a colour-coded embed.Jira — enter your Jira base URL, email, API token, project key, and issue type. Creates a Jira issue when the rule fires.Freshservice — enter your Freshservice domain and API key. Opens a ticket with priority mapped to severity.Webhook — paste any HTTPS URL. Zespan POSTs a signed JSON payload. See Webhooks for the schema and signature verification.Use Test channel after adding a channel to verify delivery before the rule goes live.
Enabling and disabling rules
Each rule has a toggle on the rule card. Disabled rules are not evaluated and will not fire. Use this to pause a noisy rule without deleting it.Alert history
The history table shows every evaluation — both triggered and not triggered — with timestamp, rule name, metric value, and threshold. Click any row to see the full evaluation details.Webhook payload
When a rule fires and a webhook channel is configured, Zespan POSTs:X-Zespan-Signature-256 header for HMAC-SHA256 verification. See Webhooks for verification code.
Model lifecycle alerts
Model Lifecycle uses this same alert delivery machinery — not a separate notification path — for a distinct rule type,model-lifecycle, that fires when the daily deprecation scan raises or re-raises a finding rather than on a metric threshold you configure.
AlertRule.type for this rule kind is not an option in the Create Alert flow described above, which is built around metric/threshold rules, and a model-lifecycle rule doesn’t appear in this page’s alert rules table either — both assume every rule has a metric, condition, and threshold, none of which a lifecycle rule has. Instead, it has its own small, dedicated opt-in: a settings card at the top of the Model Lifecycle page itself (toggle, notification emails, optional webhook). Enabling it there creates or updates the same AlertRule row this section describes, through a separate GET/PUT /v1/projects/{id}/model-lifecycle/alert-rule pair (see the API reference) rather than this page’s alert endpoints.
Next steps
- Model Lifecycle — what a finding contains and the 90/30/7/0 re-raise ladder that governs when this alert type fires again
- Incidents — where a breaching alert can escalate into a tracked incident
- Webhooks — full payload schema and signature verification for the webhook channel