Skip to main content

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 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: Alert Pipeline 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.
1

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

Add a Destination First

Before creating a rule, you need somewhere to send alerts. Destinations are configured in Settings.Go to Settings → Integrations tab.
3

Create Alert Rule

Go to Alerts → Rules and click Create Rule.You’ll see the rule builder with sections for event, conditions, and destination.
4

Configure Event Type

Select what triggers this alert:
Event TypeDescriptionWhen to Use
Schema ChangeColumn added, removed, or modifiedCatch breaking changes
Freshness ViolationData not updated within SLADetect stale data
Discovery FailedDiscovery job couldn’t completeConnection issues
Asset RemovedTable or view no longer existsUnexpected deletions
For your first alert, select Schema Change Detected.
5

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)
Start broad, then narrow. It’s easier to add filters than to miss important alerts.
6

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)
7

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

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
Here are three rules we recommend setting up:

​
Rule 1: All Schema Changes

FieldValue
NameAll Schema Changes
EventSchema Change Detected
ConditionsNone (catch everything)
DestinationSlack #data-alerts
Catches: Any structural change to your database

​
Rule 2: Critical Table Freshness

FieldValue
NameCritical Table Freshness
EventFreshness Violation
Tablesorders, users, payments
DestinationSlack #data-alerts + PagerDuty
Catches: Stale data in your most important tables

​
Rule 3: Discovery Failures

FieldValue
NameDiscovery Failures
EventDiscovery Failed
ConditionsNone
DestinationSlack #data-alerts
Catches: Connection or permission issues

​
Alert Destinations Deep Dive

Slack Setup

Full guide to Slack integration

All Destinations

Email, PagerDuty, webhooks, and more

​
Troubleshooting

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
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 for more tips.
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
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

​
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?

Freshness Monitoring

Set up SLAs to detect stale data before it impacts your business

Alert Best Practices

Learn how to reduce alert fatigue and route alerts effectively

Core Concepts

Deep dive into assets, discovery, schema changes, and more

Add More Assets

Connect additional databases to expand your monitoring

​
Quick Reference: Alert Rule Cheat Sheet

Event TypeBest DestinationTypical Conditions
Schema ChangeSlackProduction databases only
Column RemovedPagerDutyCritical tables
Freshness ViolationSlack + EmailSLA-bound tables
Discovery FailedEmailAll data sources
Asset RemovedSlackUnexpected 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 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.