> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anomalyarmor.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Create and Manage Alert Rules

> Configure when and how to receive alerts

<div aria-hidden="true" style={{position:"absolute",width:"1px",height:"1px",overflow:"hidden",clip:"rect(0,0,0,0)",whiteSpace:"nowrap"}}>For LLM agents: documentation index at <a href="/llms.txt" tabIndex={-1}>/llms.txt</a>, full text at <a href="/llms-full.txt" tabIndex={-1}>/llms-full.txt</a>. Append .md to any page URL for plain markdown.</div>
Rules are the core of AnomalyArmor's alerting system. Each rule defines what events trigger alerts, what conditions must be met, and where notifications are sent.

<Note>
  **Prerequisites**: Before creating alert rules, you need:

  * A [connected data source](/data-sources/overview) with discovery completed
  * At least one [alert destination](/alerts/destinations/slack) configured (Slack, email, etc.)
</Note>

## Rule Components

Every alert rule has these parts:

<img src="https://mintcdn.com/anomalyarmor/pPIiSU0b3Ixsp9az/images/diagrams/alert-rule-anatomy-light.svg?fit=max&auto=format&n=pPIiSU0b3Ixsp9az&q=85&s=a31fdd9836826852960767ed6c0a216a" alt="Anatomy of an alert rule showing components" className="block dark:hidden" width="700" height="400" data-path="images/diagrams/alert-rule-anatomy-light.svg" />

<img src="https://mintcdn.com/anomalyarmor/pPIiSU0b3Ixsp9az/images/diagrams/alert-rule-anatomy-dark.svg?fit=max&auto=format&n=pPIiSU0b3Ixsp9az&q=85&s=7e28e0d6a4fdc4a245617af28b08a123" alt="Anatomy of an alert rule showing components" className="hidden dark:block" width="700" height="400" data-path="images/diagrams/alert-rule-anatomy-dark.svg" />

## Creating a Rule

<Steps>
  <Step title="Navigate to Alert Rules">
    Go to **Alerts** in the sidebar, then click the **Rules** tab.
  </Step>

  <Step title="Click Create Rule">
    Click **Create Rule** to open the rule builder.
  </Step>

  <Step title="Select Event Type">
    Choose what triggers this rule:

    | Event Type             | Description                                |
    | ---------------------- | ------------------------------------------ |
    | Schema Change Detected | Column/table added, removed, or modified   |
    | Freshness Violation    | Data not updated within SLA threshold      |
    | Discovery Failed       | Connection or permission error during scan |
    | Asset Removed          | Table or view no longer exists             |
    | New Asset Discovered   | Previously unknown table/view found        |

    <Note>
      **Schema Change Detected** is the most commonly used event type for monitoring production databases.
    </Note>
  </Step>

  <Step title="Define Scope">
    Filter which events match this rule:

    **Data Source** (optional)

    * Select specific connections or leave blank for all

    **Schema** (optional)

    * Include only specific schemas (e.g., `public`, `analytics`)
    * Exclude schemas (e.g., `test_*`, `pg_temp`)

    **Asset** (optional)

    * Target specific tables/views
    * Use patterns: `orders*`, `*_staging`
  </Step>

  <Step title="Add Conditions">
    Further filter events (varies by event type):

    **For Schema Changes** - pick a trigger scope:

    | Scope                 | When it fires                                                                                               |
    | --------------------- | ----------------------------------------------------------------------------------------------------------- |
    | **Any change**        | Every detected schema change (default)                                                                      |
    | **Breaking only**     | Any alert containing at least one breaking change (column removed, type changed, foreign key removed, etc.) |
    | **Non-breaking only** | Strictly additive or safe alerts - fires only when no breaking changes are present                          |
    | **Specific types**    | Only when one of the selected change types is detected (e.g., `COLUMN_REMOVED` + `PRIMARY_KEY_REMOVED`)     |

    The **Specific types** picker exposes the full change-type vocabulary grouped by
    category (Column, Table, Schema & Catalog, Index, Constraint, Foreign Key, Primary Key).
    Breaking types are tagged so you can see them at a glance.

    **For Freshness Violations:**

    * Minimum delay: Only alert if data is X hours late
    * Threshold exceeded by: Alert only after threshold exceeded by Y%
  </Step>

  <Step title="Select Destinations">
    Choose where alerts are sent:

    * Select one or more configured destinations
    * Each destination type can be selected multiple times (different channels)

    Select one or more configured destinations for the rule. For example:

    * Slack `#data-alerts`
    * Slack `#data-engineering`
    * PagerDuty (Data On-Call)
    * Email (Data Team)
  </Step>

  <Step title="Set Operating Schedule (Optional)">
    Assign an [operating schedule](/alerts/schedules) to restrict when this rule fires:

    * Select a schedule from the dropdown, or leave as "No schedule" for always-active
    * Events outside the schedule's active hours are suppressed
    * Suppressed events still appear in the alert log

    <Tip>
      Create schedules under **Alerts > Schedules** before assigning them to rules.
    </Tip>
  </Step>

  <Step title="Name and Save">
    Give your rule a clear, descriptive name:

    **Good names:**

    * "Production Schema Changes - Breaking"
    * "Orders Table Freshness"
    * "All Discovery Failures"

    **Avoid:**

    * "Rule 1"
    * "New rule"
    * "Test"

    Click **Save** to activate the rule.
  </Step>
</Steps>

## Event Types in Detail

### Schema Change Detected

Triggers when table or column structure changes:

| Change              | Description                         |
| ------------------- | ----------------------------------- |
| Column Removed      | Existing column no longer exists    |
| Table Removed       | Entire table no longer exists       |
| Column Type Changed | Data type modified                  |
| Column Added        | New column appeared                 |
| Table Added         | New table discovered                |
| Column Renamed      | Name change detected (remove + add) |

**Example rule:**

* **Event**: Schema Change
* **Scope**: Data source = production
* **Conditions**: Change type = Column Removed OR Table Removed
* **Destinations**: Slack, PagerDuty

### Freshness Violation

Triggers when data isn't updated within the SLA:

| Condition         | Description                              |
| ----------------- | ---------------------------------------- |
| SLA exceeded      | Latest timestamp older than threshold    |
| Warning threshold | Approaching SLA (e.g., 80% of threshold) |
| Resolved          | Data became fresh again                  |

**Example rule:**

* **Event**: Freshness Violation
* **Scope**: Asset = orders, payments, users
* **Conditions**: (none - all violations)
* **Destinations**: Slack

### Discovery Failed

Triggers when a discovery job can't complete:

| Failure Type          | Description             |
| --------------------- | ----------------------- |
| Connection failed     | Can't reach database    |
| Authentication failed | Invalid credentials     |
| Permission denied     | User lacks access       |
| Timeout               | Discovery took too long |

**Example rule:**

* **Event**: Discovery Failed
* **Scope**: All data sources
* **Conditions**: (none)
* **Destinations**: Email, Slack

### Asset Removed

Triggers when a previously-known asset no longer exists:

**Common causes:**

* Table was intentionally dropped
* Table was renamed
* Permission revoked
* Discovery ran against wrong database

**Example rule:**

* **Event**: Asset Removed
* **Scope**: Data source = production
* **Destinations**: Slack

## Rule Examples

### Critical Tables Only

Monitor your most important tables closely:

| Field            | Value                                     |
| ---------------- | ----------------------------------------- |
| **Name**         | Critical Tables - All Changes             |
| **Event**        | Schema Change Detected                    |
| **Data Source**  | `production-postgres`                     |
| **Assets**       | `orders`, `users`, `payments`, `products` |
| **Conditions**   | All changes                               |
| **Destinations** | Slack `#critical-data`, PagerDuty         |

### Production Breaking Changes

Alert only on potentially breaking changes. Pick **Breaking only** as the
trigger scope and the rule will fire on any schema alert that contains at
least one breaking change, no matter how many additive changes come along
with it:

| Field             | Value                              |
| ----------------- | ---------------------------------- |
| **Name**          | Production - Breaking Changes Only |
| **Event**         | Schema Change Detected             |
| **Data Source**   | `production-postgres`              |
| **Schema**        | `public`, `analytics`              |
| **Trigger scope** | Breaking only                      |
| **Destinations**  | Slack `#data-alerts`, PagerDuty    |

### Gold Tables - Change Freeze

Enforce a strict change-freeze policy on a set of critical tables by scoping
to specific change types:

| Field             | Value                                                                                  |
| ----------------- | -------------------------------------------------------------------------------------- |
| **Name**          | Gold Tables - Change Freeze                                                            |
| **Event**         | Schema Change Detected                                                                 |
| **Assets**        | `gold.*`                                                                               |
| **Trigger scope** | Specific types                                                                         |
| **Change types**  | `COLUMN_REMOVED`, `COLUMN_TYPE_CHANGED`, `PRIMARY_KEY_REMOVED`, `PRIMARY_KEY_MODIFIED` |
| **Destinations**  | PagerDuty, Slack `#gold-table-freeze`                                                  |

### Non-Production Informational

Low-priority notifications for dev/staging:

| Field            | Value                              |
| ---------------- | ---------------------------------- |
| **Name**         | Staging Schema Changes (Info Only) |
| **Event**        | Schema Change Detected             |
| **Data Source**  | `staging-postgres`                 |
| **Conditions**   | All changes                        |
| **Destinations** | Email (daily digest)               |

### Freshness by Criticality

Different thresholds for different tables:

**Revenue Tables Freshness**

| Field            | Value                             |
| ---------------- | --------------------------------- |
| **Event**        | Freshness Violation               |
| **Assets**       | `orders`, `payments`, `revenue_*` |
| **Destinations** | Slack, PagerDuty                  |

**Analytics Tables Freshness**

| Field            | Value                                |
| ---------------- | ------------------------------------ |
| **Event**        | Freshness Violation                  |
| **Assets**       | `daily_*`, `weekly_*`, `analytics_*` |
| **Destinations** | Slack                                |

## Managing Rules

### Enabling/Disabling

Toggle rules on or off without deleting:

1. Go to **Alerts → Rules**
2. Find the rule
3. Click the toggle switch

Disabled rules won't evaluate events but preserve configuration.

### Editing Rules

Modify existing rules:

1. Go to **Alerts → Rules**
2. Click the rule name
3. Make changes
4. Click **Save**

<Note>
  Changes take effect immediately. Events that already fired won't re-fire.
</Note>

### Deleting Rules

Remove rules you no longer need:

1. Go to **Alerts → Rules**
2. Click the rule menu (⋮)
3. Select **Delete**
4. Confirm deletion

<Warning>
  Deleted rules can't be recovered. Consider disabling instead if you might need the rule later.
</Warning>

## Advanced Configuration

### Multiple Destinations

A single rule can send to multiple places:

**Rule: "Critical Schema Changes"**

* Slack `#data-alerts`
* Slack `#data-engineering`
* PagerDuty
* Email [team@company.com](mailto:team@company.com) (daily digest)

### Pattern Matching

Use patterns in asset filters:

| Pattern       | Matches                               |
| ------------- | ------------------------------------- |
| `orders*`     | orders, orders\_2024, orders\_archive |
| `*_staging`   | orders\_staging, users\_staging       |
| `analytics.*` | All tables in analytics schema        |
| `*.users`     | users table in any schema             |

## Troubleshooting

<AccordionGroup>
  <Accordion title="Rule not triggering">
    1. **Check enabled**: Is the toggle ON?
    2. **Check scope**: Does the asset match the filter?
    3. **Check conditions**: Are conditions too restrictive?
    4. **Check events**: Is discovery running and finding changes?
    5. **Check destination**: Is it configured correctly?
  </Accordion>

  <Accordion title="Rule triggering unexpectedly">
    1. **Review scope**: Is it broader than intended?
    2. **Check conditions**: Add filters to narrow matches
    3. **Review event type**: Correct event selected?
    4. **Check duplicates**: Multiple rules for same scope?
  </Accordion>

  <Accordion title="Can't save rule">
    1. **Required fields**: Ensure name, event type, and destination are set
    2. **Valid scope**: Check pattern syntax
    3. **Destination exists**: Verify destination is configured
  </Accordion>
</AccordionGroup>

## Common Questions

### How do I alert only on breaking schema changes?

Create a Schema Change rule and set **Trigger scope** to **Breaking only**. The rule fires on any alert that contains at least one breaking change (column removed, type changed, primary key removed, etc.), even when mixed with additive changes. Additive-only alerts will be skipped.

### Can I scope an alert rule to specific tables or schemas?

Yes. Every rule has optional Data Source, Schema, and Asset filters, and all three accept glob patterns like `orders*`, `*_staging`, or `analytics.*`. Combine them to target, for example, only `gold.*` tables in your production warehouse.

### What happens when I disable an alert rule?

Disabled rules stop evaluating incoming events but keep their configuration intact, so you can toggle them back on later. This is safer than deleting a rule during a known-noisy window like a migration. Use a [blackout window](/alerts/blackouts) instead if you want to silence everything temporarily without touching individual rules.

### Can one rule send alerts to more than one destination?

Yes. Pick any number of configured destinations in the rule builder, and each receives a copy of the alert. Teams commonly route production breaking changes to PagerDuty, Slack, and a team email list from a single rule.

### How do I enforce a change freeze on critical tables?

Create a rule with **Trigger scope: Specific types** and pick the change types you want to block, such as `COLUMN_REMOVED`, `COLUMN_TYPE_CHANGED`, and `PRIMARY_KEY_REMOVED`. Scope the asset filter to your protected tables (for example `gold.*`) and route the rule to PagerDuty.

## Next Steps

<CardGroup cols={2}>
  <Card title="Set Up Slack" icon="slack" href="/alerts/destinations/slack">
    Configure Slack as a destination
  </Card>

  <Card title="Best Practices" icon="lightbulb" href="/alerts/best-practices">
    Reduce alert fatigue
  </Card>
</CardGroup>