How do I configure alert rules and notifications?

Requires Pro

Quick answer

In the Alert rules section of Monitoring, use “Add rule” to define when Notory alerts you: a metric (CPU %, Memory %, Disk %, Load (1 min) or Status up/down), a comparator with a threshold, an optional duration (“For (seconds)”), and the severity. The rule applies to a specific system or to All systems. A breach creates an alert and a notification.

Prerequisites

Monitoring is part of the Operations module and available from the Pro tier.

Open alert rules. In the Monitoring module, scroll to the Alert rules section. The table shows, per rule, Rule name, Condition (e.g. CPU % > 90), Severity, Target, and whether it is Enabled.

Screenshot pending monitoring-alarmregeln-01 Alert rules section with a table of rule name, condition, severity, target and enabled status

The 'Alert rules' section with existing rules.
Create a rule. Click “Add rule” and fill in the dialog:
- Rule name (required) — e.g. “CPU sustained above 90%”.
- Metric — CPU %, Memory %, Disk %, Load (1 min) or Status (up/down).
- Comparator — >, >=, <, <= or ==.
- Threshold (required) — e.g. 90.
- For (seconds) — how long the condition must hold continuously before the alert fires (0 = immediately).
- Severity — Info, Warning or Critical.
- Target — a specific system or All systems.
- Enabled — only enabled rules are evaluated.
Screenshot pending monitoring-alarmregeln-02 'Add rule' dialog with metric, comparator, threshold, duration, severity and target

An alert rule: metric, comparator, threshold, duration and severity.
Track alerts. Triggered alerts appear under Recent alerts (state Firing/Resolved) and generate a notification — visible on the bell icon and in the Operations area.

Tip — offline alert: The Status metric returns 1 (up) or 0 (down). A rule Status == 0 with, say, For 300 seconds flags systems that have been unreachable for five minutes.

Create a rule — POST /api/v1/monitoring/alert-rules (scope write). host_id: null means “all systems”:

curl -X POST https://demo.notory.io/api/v1/monitoring/alert-rules \
  -H "Authorization: Bearer inv_dein_token" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "CPU dauerhaft über 90 %",
    "metric": "cpu_pct",
    "comparator": ">",
    "threshold": 90,
    "for_seconds": 300,
    "severity": "critical",
    "host_id": null,
    "enabled": true
  }'

{
  "id": "rl_1c2d…",
  "tenant_id": "3d9b0c12-…",
  "name": "CPU dauerhaft über 90 %",
  "metric": "cpu_pct",
  "comparator": ">",
  "threshold": 90.0,
  "for_seconds": 300,
  "severity": "critical",
  "host_id": null,
  "enabled": true,
  "created_at": "2026-07-08T11:00:00Z"
}

Allowed metric values: cpu_pct, mem_pct, disk_pct, load1, status — the API rejects other values with 400. comparator ∈ > | >= | < | <= | ==; severity ∈ info | warning | critical.

Managing rules and reading alerts:

curl -H "Authorization: Bearer inv_dein_token" \
  https://demo.notory.io/api/v1/monitoring/alert-rules

curl -X PUT https://demo.notory.io/api/v1/monitoring/alert-rules/rl_1c2d... \
  -H "Authorization: Bearer inv_dein_token" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": false }'

curl -X DELETE https://demo.notory.io/api/v1/monitoring/alert-rules/rl_1c2d... \
  -H "Authorization: Bearer inv_dein_token"

curl -H "Authorization: Bearer inv_dein_token" \
  "https://demo.notory.io/api/v1/monitoring/alerts?limit=50"

Possible errors: 400 (unknown metric), 401, 403 (the Operations module is not in your tier or no write access), 404 (rule not found), 422 (validation, e.g. a negative for_seconds).

What happens behind the scenes?

Evaluated against the latest metrics: Notory continuously checks enabled rules against the most recent values of the target systems. Only once the condition has been breached continuously for the configured duration (for_seconds) does the rule fire.
Alert lifecycle: When it fires, an alert event is created in the Firing (firing) state with the measured value; once the metric normalizes, it is marked Resolved (resolved) — including timestamps.
Notification included: For every triggered alert, Notory generates a notification — the unread counter on the bell icon increases.
Deleting a rule removes its history: Deleting a rule also deletes its alert events (cascade). Disabling it (enabled: false) stops evaluation but keeps the history.
Audit & tenant: Rules belong to your tenant; creating, changing and deleting them is logged.