How Alerts Are Evaluated
This page explains when an alert starts, when it ends, and when you are notified. Understanding it helps you choose the warm-up and cool-down of a rule.
Checks
Every minute, the Platform checks every enabled rule against the latest data of the subjects it covers, in every environment it applies to. Rules on workspace subjects, such as access tokens and credits, are checked once per minute for the whole workspace.
A check that has no data for a subject treats that subject as healthy. For message-driven subjects such as handlers, this means a handler that stops receiving messages also stops alerting. To be told when an application disappears altogether, use a rule on application replicas, such as the default Offline application rule.
If a check fails, for example because data is temporarily unavailable, nothing changes: no alert starts or resolves on missing information.
The life of an alert
condition holds lasted "Alert after"
healthy ─────────────────▶ pending ──────────────────────────▶ triggered
▲ │ │
│ recovers │ │ healthy for "Resolve after"
└──────────────────────────┘ ▼
◀───────────────────────────────────────────────────────────── resolved- Pending
-
A condition holds for the subject, but not yet for the rule’s Alert after time. Pending alerts show on the rule’s Active alerts tab and on the subject’s page, but do not open an inbox item and send no notifications. If the subject recovers while pending, the alert ends without anyone being bothered.
- Triggered
-
The problem has lasted long enough. The subject is added to an inbox item, opening one if needed, and integrations are notified. The alert stays triggered while any of the rule’s conditions holds; when one condition takes over from another, the alert continues.
- Resolved
-
The subject has been healthy for the rule’s Resolve after time. If the problem returns within that time, the alert continues as if it never stopped.
The severity of an alert is that of the most severe condition that holds right now. It changes as conditions start and stop holding, and the priority of the inbox item follows.
When you are notified
Notifications are sent per inbox item, not per subject, so a problem that hits many subjects at once sends one notification.
| Event | Notification |
|---|---|
The first subject of an item triggers |
Yes, the item is reported as triggered |
More subjects of the same item trigger |
No, they are added to the item |
The priority of the item changes |
No |
The last firing subject of an item resolves |
Yes, the item is reported as resolved |
A resolved item fires again |
Yes, the item is reported as triggered again |
The item is snoozed or archived |
No notifications while snoozed or archived |
Whether a notification reaches an integration depends on the integration’s severity and environment selection. See Integrations.
When you change a rule
Changes apply from the next check:
-
Firing alerts keep firing and their inbox items stay open; they are judged against the new conditions from then on, and resolve if they no longer breach.
-
Disabling or deleting a rule resolves its alerts.
-
Changing Split inbox by while alerts are firing moves the firing subjects into new items that match the new grouping. The old items are closed. No notifications are sent for the move.
-
An inbox item that opened under an older version of the rule shows a Rule updated since label.