> ## 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.

# Set Up Your First Alert

> Step 3 - Get notified when data issues occur

<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>
Alerts are how AnomalyArmor tells you when something needs attention. In this step, you'll create your first alert rule to get notified about schema changes.

## How Alerts Work

Alerts follow a simple flow:

<img src="https://mintcdn.com/anomalyarmor/pPIiSU0b3Ixsp9az/images/diagrams/alert-concept-overview-light.svg?fit=max&auto=format&n=pPIiSU0b3Ixsp9az&q=85&s=e3ce7fb94c6282027f918ecb1d263ea2" alt="Alert Pipeline" className="block dark:hidden" width="900" height="350" data-path="images/diagrams/alert-concept-overview-light.svg" />

<img src="https://mintcdn.com/anomalyarmor/pPIiSU0b3Ixsp9az/images/diagrams/alert-concept-overview-dark.svg?fit=max&auto=format&n=pPIiSU0b3Ixsp9az&q=85&s=3cfb4fbb3a032d3a3615d53554aed76b" alt="Alert Pipeline" className="hidden dark:block" width="900" height="350" data-path="images/diagrams/alert-concept-overview-dark.svg" />

**Three components**:

1. **Event**: What triggers the alert (schema change, freshness violation, etc.)
2. **Rule**: Conditions that filter events (optional: specific tables, change types)
3. **Destination**: Where the alert goes (Slack, email, PagerDuty, webhook)

## Step-by-Step Guide

Let's create an alert rule for schema , one of the most common and important alerts.

<Steps>
  <Step title="Navigate to Alerts">
    Click **Alerts** in the left sidebar, then select **Rules**.

    You'll see the Alert Rules page where you can create and manage your alert rules.
  </Step>

  <Step title="Add a Destination First">
    Before creating a rule, you need somewhere to send alerts. Destinations are configured in Settings.

    Go to **Settings** → **Integrations** tab.

    <Tabs>
      <Tab title="Slack (Recommended)">
        1. Click **Connect Slack App** or **Add Webhook**
        2. For Slack App: Authorize AnomalyArmor in Slack and select your channel
        3. For Webhook: Paste your Slack webhook URL
        4. Click **Save**
      </Tab>

      <Tab title="Email">
        1. Select **Email**
        2. Enter email addresses (comma-separated for multiple)
        3. Name the destination (e.g., "Data Team Email")
        4. Click **Save**
      </Tab>

      <Tab title="PagerDuty">
        1. Select **PagerDuty**
        2. Enter your PagerDuty Integration Key
        3. Name the destination
        4. Click **Save**
      </Tab>

      <Tab title="Webhook">
        1. Select **Webhook**
        2. Enter your webhook URL
        3. Configure headers if needed
        4. Click **Save**
      </Tab>
    </Tabs>
  </Step>

  <Step title="Create Alert Rule">
    Go to **Alerts** → **Rules** and click **Create Rule**.

    You'll see the rule builder with sections for event, conditions, and destination.
  </Step>

  <Step title="Configure Event Type">
    Select what triggers this alert:

    | Event Type              | Description                        | When to Use            |
    | ----------------------- | ---------------------------------- | ---------------------- |
    | **Schema Change**       | Column added, removed, or modified | Catch breaking changes |
    | **Freshness Violation** | Data not updated within SLA        | Detect stale data      |
    | **Discovery Failed**    | Discovery job couldn't complete    | Connection issues      |
    | **Asset Removed**       | Table or view no longer exists     | Unexpected deletions   |

    For your first alert, select **Schema Change Detected**.
  </Step>

  <Step title="Set Conditions (Optional)">
    Filter which schema changes trigger alerts:

    * **Data Source**: All, or specific connection
    * **Schema**: All, or specific schemas (e.g., `public`)
    * **Asset**: All, or specific tables
    * **Change Type**: All, or specific (added, removed, modified)

    **For your first rule**, keep defaults (all schema changes) or filter to:

    * **Data Source**: Your production database
    * **Change Type**: Column Removed (most critical)

    <Tip>
      Start broad, then narrow. It's easier to add filters than to miss important alerts.
    </Tip>
  </Step>

  <Step title="Select Destination">
    Choose where to send alerts from the destinations you configured:

    * Select your Slack channel, email, or other destination
    * You can select multiple destinations for the same rule

    For example, critical schema changes might go to:

    * **Primary**: Slack `#data-alerts`
    * **Escalation**: PagerDuty (for removed columns)
  </Step>

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

    **Good names**:

    * "Production Schema Changes"
    * "Critical Table Monitoring - orders"
    * "Dev Schema Changes (Low Priority)"

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

  <Step title="Test Your Alert">
    Verify the alert is working:

    1. Go to **Settings** → **Integrations**
    2. Find your destination and look for a test option
    3. Check that the test message arrives in your Slack channel or email
  </Step>
</Steps>

## Recommended First Rules

Here are three rules we recommend setting up:

### Rule 1: All Schema Changes

| Field           | Value                   |
| --------------- | ----------------------- |
| **Name**        | All Schema Changes      |
| **Event**       | Schema Change Detected  |
| **Conditions**  | None (catch everything) |
| **Destination** | Slack #data-alerts      |

Catches: Any structural change to your database

### Rule 2: Critical Table Freshness

| Field           | Value                          |
| --------------- | ------------------------------ |
| **Name**        | Critical Table Freshness       |
| **Event**       | Freshness Violation            |
| **Tables**      | orders, users, payments        |
| **Destination** | Slack #data-alerts + PagerDuty |

Catches: Stale data in your most important tables

### Rule 3: Discovery Failures

| Field           | Value              |
| --------------- | ------------------ |
| **Name**        | Discovery Failures |
| **Event**       | Discovery Failed   |
| **Conditions**  | None               |
| **Destination** | Slack #data-alerts |

Catches: Connection or permission issues

## Alert Destinations Deep Dive

<CardGroup cols={2}>
  <Card title="Slack Setup" icon="slack" href="/alerts/destinations/slack">
    Full guide to Slack integration
  </Card>

  <Card title="All Destinations" icon="bell" href="/alerts/overview">
    Email, PagerDuty, webhooks, and more
  </Card>
</CardGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Alerts not firing">
    **Check these in order**:

    1. **Rule is enabled**: Toggle should be ON in the Rules list
    2. **Destination is configured**: Test the destination
    3. **Conditions match**: Are your filters too restrictive?
    4. **Events are occurring**: Check Discovery is running and finding changes
  </Accordion>

  <Accordion title="Too many alerts">
    **Reduce noise with filters**:

    1. Add conditions to target specific tables
    2. Filter out development/test schemas
    3. Filter by change type (e.g., only column removals)
    4. Use different destinations for different event types

    See [Alert Best Practices](/alerts/best-practices) for more tips.
  </Accordion>

  <Accordion title="Slack alerts not appearing">
    **Common causes**:

    1. Bot not invited to private channels: Type `/invite @AnomalyArmor`
    2. OAuth expired: Reconnect the Slack destination
    3. Channel archived: Select a different channel
  </Accordion>

  <Accordion title="Test alert works but real alerts don't">
    **The rule conditions might not match**:

    1. Verify discovery is running and finding assets
    2. Check rule conditions aren't filtering out all events
    3. Wait for the next discovery run to detect changes
    4. Manually trigger a schema change in a test table to verify
  </Accordion>
</AccordionGroup>

## What You've Accomplished

Congratulations! You've completed the quickstart. You now have:

-A database connected to AnomalyArmor
-Your data assets discovered and cataloged
-Alert rules configured to notify you of issues

## What's Next?

<CardGroup cols={2}>
  <Card title="Freshness Monitoring" icon="clock" href="/data-quality/freshness-monitoring">
    Set up SLAs to detect stale data before it impacts your business
  </Card>

  <Card title="Alert Best Practices" icon="lightbulb" href="/alerts/best-practices">
    Learn how to reduce alert fatigue and route alerts effectively
  </Card>

  <Card title="Core Concepts" icon="book" href="/concepts/overview">
    Deep dive into assets, discovery, schema changes, and more
  </Card>

  <Card title="Add More Assets" icon="database" href="/quickstart/connect-first-database">
    Connect additional databases to expand your monitoring
  </Card>
</CardGroup>

***

## Quick Reference: Alert Rule Cheat Sheet

| Event Type          | Best Destination | Typical Conditions        |
| ------------------- | ---------------- | ------------------------- |
| Schema Change       | Slack            | Production databases only |
| Column Removed      | PagerDuty        | Critical tables           |
| Freshness Violation | Slack + Email    | SLA-bound tables          |
| Discovery Failed    | Email            | All data sources          |
| Asset Removed       | Slack            | Unexpected only           |

## Common Questions

### What destinations can AnomalyArmor send alerts to?

Slack, Email, PagerDuty, Microsoft Teams, Linear, incident.io, and custom webhooks. Each destination is configured once under **Settings → Integrations** and then reused across alert rules. See [Alerts Overview](/alerts/overview) for the full list.

### How do I stop getting alerts for a specific table without disabling the whole rule?

Add an exclude condition on the alert rule: filter by asset name, schema, or tag. This keeps the rule active for everything else while muting the noisy table. Blackout windows work too if the noise is time-bounded (overnight batch loads, planned migrations).

### Can I route different alert types to different channels or people?

Yes - that's the recommended pattern. Create separate rules per event type (schema change, freshness violation, discovery failure) with their own destinations. Schema drops typically page on-call via PagerDuty; freshness lapses go to team Slack; discovery errors email the data platform team.

### Why didn't my alert fire when the data issue happened?

Three common causes: (1) the rule's conditions didn't match the specific event, (2) the rule is scoped to a different asset or schema, (3) the destination is misconfigured (stale Slack webhook, revoked token). Check **Alerts → Rule History** to see which events matched the rule and whether delivery succeeded.

### Can I test an alert rule before turning it on?

Yes. Every rule has a **Test Send** button that fires a sample alert to the destination so you can verify formatting and channel routing. Use it before enabling rules in production.