The first rule: alert on outcomes, not internals
Bad monitoring pages on-call when CPU spikes. Good monitoring pages on-call when data is wrong or late. The two are very different. CPU is an internal symptom; freshness and correctness are the SLAs that consumers actually care about.
The four signals every pipeline should emit
- Freshness. When did this table last update? Compare against the SLA ("by 9 AM daily"). Alert if older than the threshold.
- Volume. How many rows landed this run? Alert if outside the trailing-7-day band (e.g. ±3σ).
- Schema. Did the columns change shape? Validation failures should page; soft drift should warn.
- Distribution. Did the values shift? Mean / median / null-rate / cardinality compared to last week.
The escalation ladder
Not every signal is a page. Tune your alerting so:
- Page on broken contracts: schema changes, data missing past SLA, validation hard-failures.
- Slack on warning signals: row counts outside band, distribution drift.
- Dashboard on everything: every run's metrics, plotted over time.