API: alerting
Optional plugin. Enable per application in Settings → Plugins (or POST /?api=plugins {"id":"alerts","enabled":true}); every route below 404s while disabled. See Alerting for how triggers, spike detection, and delivery actually work.
Channels — /?api=alert-channels
| Method | Purpose |
|---|---|
| GET | List channels: {data:[…]}, each with id, name, type, enabled, target_hint (host only — the webhook URL itself is never returned). |
| POST | Create: {name, type, url, enabled?}. type is slack, discord, or webhook; url must be https://. 201. |
| PATCH/PUT | Update by id. Omit url to keep the stored one. |
| DELETE | Remove by id — its rules are removed too. |
POST /?api=alert-test {"id":N} sends a test notification: {ok, detail}.
Rules — /?api=alert-rules
| Field | Type | Notes |
|---|---|---|
name | string | Required. |
channel_id | int | Must reference an existing channel. |
trigger_type | enum | new_error, reoccurrence, or spike. |
severities | string[] | Empty = any severity. |
module_id | int, nullable | Restrict to one module. |
min_count | int | new_error: minimum group count. spike: minimum occurrences in the last hour. |
spike_factor | float | spike only: fire when the last hour exceeds this × the 24h hourly baseline. Default 3. |
cooldown_minutes | int | Minimum gap between deliveries for this rule. |
CRUD is GET/POST/PATCH·PUT/DELETE, same shape as channels.
POST /?api=alert-rules
{"name":"Critical billing errors","channel_id":4,"trigger_type":"new_error","severities":["CRITICAL","ERROR"],"module_id":3,"min_count":1,"cooldown_minutes":0}
GET /?api=alert-events&limit=25 — the delivery log: {data:[{rule_id, channel_id, trigger_type, status, detail, created_at}]}, status is sent or failed.
Related
- Alerting — trigger semantics, the exact spike-detection formula, why re-syncing can't spam you.
- API conventions