Alerts follow a simple pipeline: events are detected during discovery, evaluated against your rules, and routed to destinations like Slack, email, or PagerDuty.
## 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](/alerts/blackouts) 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