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

# Alerts Overview

> Get notified when data issues occur through flexible alert routing

<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 notifies you when something needs attention. Whether it's a schema change, stale data, or a failed discovery job, alerts ensure the right people know at the right time.

<Frame caption="Alert pipeline from event to notification">
  <img src="https://mintcdn.com/anomalyarmor/qiFTglXM5puNhBYZ/images/diagrams/alert-lifecycle-light.svg?fit=max&auto=format&n=qiFTglXM5puNhBYZ&q=85&s=30e3e92cecc8171e3386b46fad7bea7f" alt="Diagram showing event detection, rule evaluation, routing, and delivery" className="block dark:hidden" width="900" height="260" data-path="images/diagrams/alert-lifecycle-light.svg" />

  <img src="https://mintcdn.com/anomalyarmor/pPIiSU0b3Ixsp9az/images/diagrams/alert-lifecycle-dark.svg?fit=max&auto=format&n=pPIiSU0b3Ixsp9az&q=85&s=b4566eb24fc944ad933960b11ebfc7b3" alt="Diagram showing event detection, rule evaluation, routing, and delivery" className="hidden dark:block" width="900" height="260" data-path="images/diagrams/alert-lifecycle-dark.svg" />
</Frame>

## How Alerts Work

Alerts follow a three-stage pipeline:

<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 from event detection to delivery" 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 from event detection to delivery" className="hidden dark:block" width="900" height="350" data-path="images/diagrams/alert-concept-overview-dark.svg" />

### 1. Event Detection

AnomalyArmor detects events during discovery runs:

| Event Type              | Description                            |
| ----------------------- | -------------------------------------- |
| **Schema Change**       | Column added, removed, or type changed |
| **Freshness Violation** | Data not updated within SLA            |
| **Discovery Failed**    | Connection or permission error         |
| **Asset Removed**       | Table/view no longer exists            |
| **New Asset**           | Table/view discovered for first time   |

### 2. Rule Evaluation

Each event is checked against your alert rules:

* **Scope**: Does the event match the rule's filters? (data source, schema, asset)
* **Conditions**: Does it meet additional criteria? (change type, etc.)
* **Active**: Is the rule enabled?

### 3. Suppression Check

<Frame caption="Alert suppression pipeline: schedule, blackout, cooldown, and daily limit checks">
  <img src="https://mintcdn.com/anomalyarmor/pPIiSU0b3Ixsp9az/images/diagrams/alert-suppression-flow-light.svg?fit=max&auto=format&n=pPIiSU0b3Ixsp9az&q=85&s=074ec830d5541a80cceef50e3c53868e" alt="Flow diagram showing alert passing through schedule check, blackout check, cooldown, and daily limit before delivery or suppression" className="block dark:hidden" width="900" height="290" data-path="images/diagrams/alert-suppression-flow-light.svg" />

  <img src="https://mintcdn.com/anomalyarmor/pPIiSU0b3Ixsp9az/images/diagrams/alert-suppression-flow-dark.svg?fit=max&auto=format&n=pPIiSU0b3Ixsp9az&q=85&s=4c4aa850d77da58c46fbf94714d01a4f" alt="Flow diagram showing alert passing through schedule check, blackout check, cooldown, and daily limit before delivery or suppression" className="hidden dark:block" width="900" height="290" data-path="images/diagrams/alert-suppression-flow-dark.svg" />
</Frame>

Before delivery, alerts pass through suppression checks:

* **[Operating Schedules](/alerts/schedules)**: Is the event within the rule's active hours?
* **[Blackout Windows](/alerts/blackouts)**: Is a company-wide blackout currently active?
* **Cooldown**: Has this rule already fired recently?
* **Daily Limit**: Has the rule exceeded its daily notification cap?

Suppressed alerts are still recorded in the alert log for auditing.

### 4. Routing & Delivery

Matching events are sent to configured destinations:

* Rules can have multiple destinations
* Each destination can receive from multiple rules
* Deduplication prevents repeat alerts for the same event

## Supported Destinations

<CardGroup cols={3}>
  <Card title="Slack" icon="slack" href="/alerts/destinations/slack">
    Real-time channel notifications
  </Card>

  <Card title="Email" icon="envelope" href="/alerts/destinations/email">
    Individual or team distribution
  </Card>

  <Card title="Webhooks" icon="code" href="/alerts/destinations/webhooks">
    Custom integrations
  </Card>

  <Card title="PagerDuty" icon="bell" href="/alerts/destinations/pagerduty">
    On-call escalation
  </Card>

  <Card title="MS Teams" icon="users" href="/alerts/destinations/ms-teams">
    Teams channel notifications
  </Card>
</CardGroup>

## Alert Components

### Rules

Rules define **when** alerts fire and **where** they go:

**Example: "Production Schema Changes"**

* **Event Type**: Schema Change Detected
* **Scope**: Data source = production-postgres
* **Conditions**: Change type = Column Removed
* **Destinations**:
  * Slack (#data-alerts)
  * PagerDuty (on-call)

See [Alert Rules](/alerts/alert-rules) for detailed configuration.

### Destinations

Destinations are the channels where alerts are delivered:

**Example: "Slack - Data Alerts"**

* **Type**: Slack
* **Channel**: #data-alerts
* **Workspace**: your-company.slack.com
* **Status**: Connected

Configure destinations before creating rules that use them.

### Alert History

All alerts are logged for review:

* View past alerts in **Alerts → History**
* Filter by date, type, destination, or asset
* See which rules triggered each alert
* Track response times and patterns

## Setting Up Alerts

### Quick Start

1. **Add a destination**: Connect Slack, email, or another channel
2. **Create a rule**: Define what triggers alerts and where they go
3. **Test**: Use "Send Test Alert" to verify delivery
4. **Monitor**: Review alert history and adjust thresholds

### Recommended First Rules

Start with these three rules:

| Rule              | Event               | Destination | Why                         |
| ----------------- | ------------------- | ----------- | --------------------------- |
| Schema Changes    | Schema Change       | Slack       | Catch breaking changes      |
| Stale Data        | Freshness Violation | Slack       | Detect pipeline failures    |
| Connection Issues | Discovery Failed    | Email       | Know when monitoring breaks |

## Alert Deduplication

AnomalyArmor prevents alert storms:

* **Same event**: Won't re-alert for the same change until resolved
* **Cooldown period**: Configurable delay between repeated alerts
* **Incident correlation**: When one upstream cause cascades through your lineage,
  the downstream alerts are grouped into a single incident with a named root cause
  and a visible blast radius, instead of one alert per affected table. See
  [Incident Correlation](/alerts/incident-correlation).

## Managing Alerts

### Viewing Active Alerts

Go to **Alerts → Active** to see unresolved alerts:

* Filter by asset or date
* Click to view details and related changes
* Mark as acknowledged or resolved

### Disabling Rules

To temporarily stop alerts during maintenance:

1. Go to **Alerts → Rules**
2. Find the rule and toggle it **OFF**
3. After maintenance, toggle it back **ON**

### Reviewing History

**Alerts → History** shows all past alerts:

* When each alert fired
* Which rule triggered it
* Where it was delivered
* Alert details and context

Use history to:

* Identify alert fatigue (too many alerts)
* Find patterns (same asset always alerting)
* Tune thresholds and conditions

## Best Practices

<AccordionGroup>
  <Accordion title="Start with critical assets">
    Don't alert on everything. Begin with your most important tables (revenue, users, orders) and expand from there.
  </Accordion>

  <Accordion title="Match channels to urgency">
    * **PagerDuty**: Only for truly urgent issues requiring immediate response
    * **Slack**: Team visibility, moderate urgency
    * **Email**: Low urgency, informational, digests
  </Accordion>

  <Accordion title="Set realistic thresholds">
    If your data updates hourly, don't set a 30-minute freshness SLA. Start lenient and tighten over time.
  </Accordion>

  <Accordion title="Review and tune regularly">
    Check alert history weekly. If you're getting too many alerts, adjust rules. If you're missing issues, add coverage.
  </Accordion>
</AccordionGroup>

See [Alert Best Practices](/alerts/best-practices) for more detailed guidance.

## Troubleshooting

<AccordionGroup>
  <Accordion title="Alerts not firing">
    1. Check rule is enabled (toggle ON)
    2. Verify destination is connected (test it)
    3. Confirm scope matches the asset
    4. Ensure events are occurring (check discovery is running)
  </Accordion>

  <Accordion title="Too many alerts">
    1. Add conditions to filter events
    2. Exclude development/test schemas
    3. Increase thresholds (e.g., longer freshness SLA)
    4. Route different event types to different destinations
  </Accordion>

  <Accordion title="Wrong destination receiving alerts">
    1. Check rule configuration
    2. Verify destination is selected for the correct rule
    3. Check for duplicate rules with different destinations
  </Accordion>
</AccordionGroup>

## Common Questions

### What kinds of events can AnomalyArmor alert on?

AnomalyArmor alerts on schema changes (columns or tables added, removed, or retyped), freshness violations when data falls behind its SLA, discovery failures from connection or permission errors, assets that have been removed, and newly discovered tables or views. See [Alert Rules](/alerts/alert-rules) for the full event vocabulary.

### How does AnomalyArmor prevent alert storms?

Every event passes through cooldown, daily-limit, and deduplication checks before delivery. The same unresolved event will not re-alert, and multiple related changes to one table are grouped into a single notification. Review [Best Practices](/alerts/best-practices) for additional tuning.

### Can one alert rule send to multiple destinations?

Yes. A single rule can fan out to Slack, PagerDuty, email, and any other configured destination at the same time, and the same destination can receive from many rules. This is how teams route breaking changes to PagerDuty while also posting them to a Slack channel for visibility.

### Where do I see alerts that were suppressed by a schedule or blackout?

Suppressed alerts still appear under **Alerts > History** with the suppression reason recorded (`outside operating hours`, `blackout period`, `cooldown`, or `daily limit`). Nothing is ever silently dropped.

### What are the first alert rules I should set up?

Start with three: schema changes on your production database routed to Slack, freshness violations on revenue tables routed to Slack, and discovery failures routed to email. Expand from there once you know the volume. See [Best Practices](/alerts/best-practices) for a recommended starting configuration.

## Next Steps

<CardGroup cols={2}>
  <Card title="Create Alert Rules" icon="plus" href="/alerts/alert-rules">
    Configure when and where alerts fire
  </Card>

  <Card title="Set Up Slack" icon="slack" href="/alerts/destinations/slack">
    Connect your Slack workspace
  </Card>

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

  <Card title="Freshness SLAs" icon="clock" href="/data-quality/freshness-monitoring">
    Set up data freshness alerts
  </Card>
</CardGroup>