Alerts notify 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.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.
What Triggers Alerts
| Event Type | Description |
|---|---|
| Schema Change | Column added, removed, or type changed |
| Freshness Violation | Data not updated within SLA |
| Metric Anomaly | Value outside expected range |
| Discovery Failed | Connection or permission error |
| Asset Removed | Table/view no longer exists |
Common Questions
What’s the difference between an event, a rule, and a destination?
An event is something detected (schema change, freshness violation, metric anomaly). A rule is your filter on events - which assets, which event types, severity thresholds, schedule conditions. A destination is where the notification lands (Slack, email, PagerDuty, webhook). Events flow through rules to destinations.Can one event fire multiple alerts to different destinations?
Yes - that’s the normal pattern. A production schema drop might page on-call via PagerDuty and post to the team Slack channel and email the data-platform list. Each is a separate rule with the same event filter but different destinations.Do I configure alerts per table, or globally?
Either. Rules can apply to all assets (useful for catching discovery failures across everything) or be scoped to specific schemas, tags, or individual assets. Most teams start with a global “schema drop” rule and add tighter per-critical-table rules over time.Can I suppress alerts during a planned migration or deploy?
Yes. Use blackout windows to pause alerting on specific assets or rules for a defined time window. Events are still recorded; they just don’t notify until the window ends.Next Steps
Create Alert Rules
Define when and where alerts fire
Connect Destinations
Set up Slack, email, or other channels