> For the complete documentation index, see [llms.txt](https://docs.decube.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decube.io/data-quality-v2/alerts/how-alert-rules-work.md).
# How alert rules work
Key concepts the make up every alert rule in the Data Quality module.
### Rule
An alert rule is the unit of configuration on the Alerts page. Every rule has a name, a scope, optionally filters, and one or more actions. A rule is either enabled or disabled — a disabled rule is never evaluated, but its configuration is kept, so you can turn it back on later without rebuilding it from scratch.
### Trigger
**What causes a rule to be checked?**
Currently only one trigger is supported: incident generated. Every time a monitor run — scheduled or Manual — fails and produces a new incident, every enabled rule is evaluated once against it.
In the roadmap, we plan to add more trigger types to accommodate different requirements, eg. trigger when “incidents has been generated five times in a day”.
### Scope
**Which monitors does this rule apply to?**
Scope is the first real decision in the rule builder, and it has two options:
* **All monitors** — the rule is a candidate for every monitor in the workspace. You then narrow it down with Filters (see below).
* **Specific monitors** — you pick an exact list of monitors from a picker, by name. This is useful for pinning together a named group of monitors that don't share a common attribute or type — for example, a hand-picked list of monitors on your most business-critical pipelines.
Choosing Specific monitors replaces Filters entirely — there's no filtering on top of a pinned list.
### Filters
**How do I narrow "All monitors" down to the incidents I actually care about?**
Filters only appear when Scope is set to All monitors. You can combine:
* **Monitor type** — multi-select, for example Freshness – SLA, Volume, Null, Custom SQL.
* **Custom attributes** — the same attribute system used elsewhere in Decube (severity, domain, team, etc.) — matches on attributes set on the monitor.
* **Monitor name** — contains, or does not contain, a text string.
Each row after the first has an AND/OR toggle that joins it to the row before it. If you're mixing AND and OR, use Preview matching monitors to confirm the rule captures what you expect before saving.
A rule with no filters at all — Scope: All monitors, no filter rows added — matches **every** incident.
### Actions
**Where does the alert actually go?**
A rule can have one or more actions. List of alert channels available are in [Alert channels](/data-quality-v2/alerts/alert-channels.md).
A single rule can fire multiple actions at once — for example, posting to Slack **and** sending an email for the same incident. Each configured action has its own test send: a hardcoded test message delivered through the real channel, so you can confirm the destination is wired up correctly before you rely on it. A test send doesn't evaluate any rule and doesn't carry real incident data.
### Enable / disable
A rule can be toggled off without deleting it — useful when you're tuning a new rule and want to pause it temporarily, or when a destination (like a Slack channel) is being renamed and you don't want stray alerts going to a dead channel in the meantime.
### How multiple rules interact
Every enabled rule is evaluated independently against every incident. If two rules both match the same incident, both fire — for example, a broad rule that Slacks every Freshness incident, and a narrower rule that also emails a specific team when their custom attributes match, can both trigger from the same incident.
