Alert Rules & Notifications

How Alerting Works

Every check result is evaluated against the check's alert rules. When a rule's condition is met and no incident is open for the check, an incident is created and notifications are sent to the rule's channels. When the check recovers and no rule still fires, the incident auto-resolves (and optionally sends a recovery notification).

Alert Conditions

A rule's condition object keys combine additively — the rule fires when ANY key matches. The API validates conditions on write; unrecognized shapes are rejected with a 400 naming the accepted forms, so a rule that can never fire cannot be created.

Key	Example	Meaning
`health_status`	`"down"`	Fires while the check is failing
`failure_threshold`	`3`	Fires after N consecutive failures
`response_time_ms`	`2000`	Fires when response time exceeds N ms
`dns_changed`	`true`	Fires when the DNS record changes (event-based)
`ssl_days_remaining`	`14`	Fires when an ssl check reports the certificate expires within N days
`severity`	`"critical"`	Incident severity: warning \| critical \| info (metadata only)

A legacy structured form is also accepted: {"type": "consecutive_failures"|"response_time"|"ssl_expiry", "threshold": N, "operator": "gte"} (operator optional, gte is the only supported value).

Example

{
  "name": "Production API Down",
  "condition": {"failure_threshold": 2, "severity": "critical"},
  "notification_channel_ids": ["<channel-uuid>"],
  "notify_on": "unhealthy"
}

Notification Channels

Type	Config	Notes
`email`	`{"email": "ops@example.com"}`	Sent via SMTP
`ntfy`	`{"topic": "alerts"}`	Push notifications, server optional (defaults to ntfy.sh)
`webhook`	`{"url": "https://...", "secret": "optional"}`	HTTP POST; optional HMAC-SHA256 signature (`X-Quismon-Signature`), retried on failure
`slack`	`{"webhook_url": "https://hooks.slack.com/..."}`	Slack incoming webhook

Channel messages support template variables such as {{check_name}}, {{error_message}}, {{failure_count}} — see GET /v1/template-variables.

Consuming alerts from AI agents

Agents don't need to poll. Three options, fastest first:

SSE stream: GET /v1/stream/alerts with your API key — a live, org-scoped stream of every alert. Resume after disconnect with Last-Event-ID; ?since=0-0 replays the current buffer.
Webhook: point a webhook channel at your agent's endpoint; deliveries are signed (X-Quismon-Signature) and retried.
ntfy: subscribe the agent to an ntfy topic — a ready-made push stream.

notify_on

unhealthy (default) — notify when the rule fires
healthy — notify on recovery only
both — notify on firing and recovery

Incidents

Incidents are created when a rule fires and no incident is open (single-fire per episode), and resolved when the check recovers AND no rule still fires — this prevents flapping on threshold rules that fire while the endpoint is healthy (e.g. ssl_days_remaining). Incidents can be acknowledged or resolved manually via the API.

← All Docs