Create and Manage Alert Rules

Configure when and how to receive alerts

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.

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

1. Navigate to Alert Rules

   Go to Alerts in the sidebar, then click the Rules tab.

2. Click Create Rule

   Click Create Rule to open the rule builder.

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

4. 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
5. Add Conditions

   Further filter events (varies by event type):

   For Schema Changes:

   • Change type: Column Added, Column Removed, Type Changed, Table Added, Table Removed
   • Affected column pattern: *_id, created_*

   For Freshness Violations:

   • Minimum delay: Only alert if data is X hours late
   • Threshold exceeded by: Alert only after threshold exceeded by Y%
6. 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)
7. 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

   Create schedules under Alerts > Schedules before assigning them to rules.

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

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:

Field	Value
Name	Production - Breaking Changes Only
Event	Schema Change Detected
Data Source	production-postgres
Schema	public, analytics
Change Type	Column Removed, Table Removed, Type Changed
Destinations	Slack #data-alerts, PagerDuty

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

Changes take effect immediately. Events that already fired won’t re-fire.

Deleting Rules

Remove rules you no longer need:

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

Deleted rules can’t be recovered. Consider disabling instead if you might need the rule later.

Advanced Configuration

Multiple Destinations

A single rule can send to multiple places:

Rule: “Critical Schema Changes”

• Slack #data-alerts
• Slack #data-engineering
• PagerDuty
• Email [e-mail] (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

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?

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?

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

Next Steps

Set Up Slack

Configure Slack as a destination

Best Practices

Reduce alert fatigue