Skip to main content
Alert rules monitor platform metrics and trigger notifications when thresholds are breached. Each rule defines a metric, comparison operator, threshold, time window, and destinations. See Platform — Alert Rules for the operator guide and Notifications API for configuring destinations. All endpoints require tenant context and RBAC:
  • viewer / editor / admin can list and read
  • editor / admin can create, update, and delete

GET /api/v1/alerts

List all alert rules for the tenant.

Response


POST /api/v1/alerts

Create a new alert rule. Editor or Admin.

Request Body

Supported metrics

The metric field is a free-form string at the API layer — the evaluator recognizes the names above (SUPPORTED_METRICS in lib/analytics/metrics.ts). A rule whose metric is not in this list is stored, but every evaluation resolves to status: "unsupported_metric" and never fires. suppression_rate and empty_candidate_rate are also the two signals the Decision Sentinel cron watches.

Channel shapes

The channels array accepts three shapes (mix and match allowed):
Configure destinations under Settings → Integrations → Notifications or via POST /api/v1/notifications/providers.

Example

Response (201)

Returns the created alert rule.

GET /api/v1/alerts/:id

Get a single alert rule by ID.

PUT /api/v1/alerts/:id

Update an existing alert rule. All fields are optional. Editor or Admin.

DELETE /api/v1/alerts/:id

Delete an alert rule. Editor or Admin. Returns 204 No Content.

Rule lifecycle status

The status field reflects the outcome of the most recent evaluation: The evaluator runs on every cron tick — see Cron for the /api/cron/tick entry point.