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.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.
Prerequisites: Before creating alert rules, you need:
- A connected data source with discovery completed
- At least one alert destination configured (Slack, email, etc.)
Rule Components
Every alert rule has these parts:
Creating a Rule
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 |
Schema Change Detected is the most commonly used event type for monitoring production databases.
Define Scope
Filter which events match this rule:Data Source (optional)
- Select specific connections or leave blank for all
- Include only specific schemas (e.g.,
public,analytics) - Exclude schemas (e.g.,
test_*,pg_temp)
- Target specific tables/views
- Use patterns:
orders*,*_staging
Add Conditions
Further filter events (varies by event type):For Schema Changes - pick a trigger scope:
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:
| 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) |
- Minimum delay: Only alert if data is X hours late
- Threshold exceeded by: Alert only after threshold exceeded by Y%
Select Destinations
Choose where alerts are sent:
- Select one or more configured destinations
- Each destination type can be selected multiple times (different channels)
- Slack
#data-alerts - Slack
#data-engineering - PagerDuty (Data On-Call)
- Email (Data Team)
Set Operating Schedule (Optional)
Assign an operating schedule 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
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) |
- 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 |
- 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 |
- 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
- 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 |
| Field | Value |
|---|---|
| Event | Freshness Violation |
| Assets | daily_*, weekly_*, analytics_* |
| Destinations | Slack |
Managing Rules
Enabling/Disabling
Toggle rules on or off without deleting:- Go to Alerts → Rules
- Find the rule
- Click the toggle switch
Editing Rules
Modify existing rules:- Go to Alerts → Rules
- Click the rule name
- Make changes
- Click Save
Changes take effect immediately. Events that already fired won’t re-fire.
Deleting Rules
Remove rules you no longer need:- Go to Alerts → Rules
- Click the rule menu (⋮)
- Select Delete
- Confirm deletion
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 (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
Rule not triggering
Rule not triggering
- Check enabled: Is the toggle ON?
- Check scope: Does the asset match the filter?
- Check conditions: Are conditions too restrictive?
- Check events: Is discovery running and finding changes?
- Check destination: Is it configured correctly?
Rule triggering unexpectedly
Rule triggering unexpectedly
- Review scope: Is it broader than intended?
- Check conditions: Add filters to narrow matches
- Review event type: Correct event selected?
- Check duplicates: Multiple rules for same scope?
Can't save rule
Can't save rule
- Required fields: Ensure name, event type, and destination are set
- Valid scope: Check pattern syntax
- Destination exists: Verify destination is configured
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 likeorders*, *_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 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 asCOLUMN_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
Set Up Slack
Configure Slack as a destination
Best Practices
Reduce alert fatigue