---
url: https://docs.zenavo.app/operations/alert-rules
---

# Alert Rules

Alert rules notify you when something crosses a threshold you choose: a server or service that stays busy, or logs that keep printing the same error. They add to the built-in [notifications](https://docs.zenavo.app/operations/notifications), which every plan keeps. Alert rules are included in the **Pro** plan and up: 20 rules on Pro, 100 on Team.

## Add a rule

Team owners and admins open **Account settings → Alert Rules** (for the team selected in the sidebar) and click **Add rule**. Choose what the rule watches:

| Watch | Threshold | Fires when |
| --- | --- | --- |
| **Server CPU** | Percent of all its cores | Every sample in the last *N* minutes is at or above the threshold |
| **Server memory** | Percent in use | Same |
| **Server disk** | Percent in use | Same |
| **Service CPU** | vCPU, all instances together (1 vCPU = one core) | Same |
| **Service memory** | MiB, all instances together | Same |
| **Log lines** | Number of lines | At least that many lines containing the text were printed in the last *N* minutes |

*N* is from 1 to 60 minutes. Metrics are sampled about once a minute, so a rule needs samples covering its whole window before it fires: one high sample after a quiet period does not count. A server that stops reporting (for example while it is offline) keeps its rule's state; the built-in **Server offline** notification covers that case.

A **Log lines** rule watches one service of a project, or all of them. The text is matched anywhere in the line and is not case-sensitive, after variable values are redacted. Lines are counted as they are written; they are never stored for rules and never sent in alerts.

Rules are checked every minute. The list shows each rule's last value and **Firing** while its condition holds. Changing a rule starts it over. Adding, changing and deleting rules is recorded in the [audit log](https://docs.zenavo.app/account/audit-log).

## Alerts

A rule that fires sends **Alert rule fired** to the team: emails to the members who have it on (owners and admins by default, like the other [notifications](https://docs.zenavo.app/operations/notifications#who-gets-them)) and posts to the team's [channels](https://docs.zenavo.app/operations/notifications#channels) that subscribe to it. When the condition stops holding, a **Recovered** message follows.

Each rule alerts at most once an hour. If it fires again within the hour, it shows **Firing** in the console but sends nothing, and no recovery either.

Alerts name the rule, what it watches, the condition and the value seen, such as *lowest 86% in that time* or *14 matching lines*. They never include log text, variable values or secrets.

## Plans

On plans without alert rules, the page explains which plan includes them. A team that moves to such a plan keeps its rules: they stop being checked, and can still be edited, turned off or deleted, but not turned on or added. They resume by themselves once the team is back on Pro or Team.

## API

| Method | Path | |
| --- | --- | --- |
| `GET` `POST` | `/api/teams/{tid}/alert-rules` | List rules, or add one: `{kind, name, threshold, window_minutes}` with `server_id` for `server_cpu`, `server_memory` and `server_disk`; `project_id` and `service` for `service_cpu` (millicores) and `service_memory` (MiB); `project_id`, `pattern` and optionally `service` for `log_match` |
| `PATCH` `DELETE` | `/api/teams/{tid}/alert-rules/{rid}` | Change any field but `kind`, or `enabled`; remove |

Creating or turning on a rule without a plan that includes them returns 402 with [`plan_required`](https://docs.zenavo.app/api/overview#conventions).