Do I need to buy a data observability platform to start?

No. Start with dbt tests for schema/null/unique, add Soda Core or Great Expectations for distributions and freshness, wire gates in your orchestrator, and export metrics to Prometheus/Grafana. You can add a managed tool later if you need lineage and auto-detection at scale.

How do I handle schema changes without breaking everything?

Use versioned data contracts. Introduce `orders_v1_3` with a clear migration path, backfill, and a cutover window. Block producers from mutating `v1_2` without a version bump. In the warehouse, use views to present a stable interface while you migrate.

What SLOs should I start with?

Start simple: Freshness (99.9% within 15 min), Completeness (row count within ±10% of 7-day average), and Accuracy (one or two core business invariants). Publish them, attach owners, and review weekly. Add more only when they change business outcomes.

How do I avoid alert fatigue?

Alert on multi-signal and SLO burn, not individual test failures. Route pages to the owning team, and send everything else as FYI. Track precision/recall of alerts: if >30% are false positives, tune thresholds or move to canary-only paging.

Where should the checks live?

With the code. Put dbt tests next to dbt models, Soda/GE scans in the repo, and contract validators in the ingest service. Run them in CI on PRs and in prod on every run. Checks that aren’t versioned drift out of truth.

Data-engineering · Oct 28, 2025 · 9 minute read

Circuit Breakers for Data: Quality Monitoring That Stops Bad Loads Before They Wreck Analytics

You don’t need another dashboard about your dashboards. You need guardrails that block bad data before it hits finance, product, or ML.

Back to all posts

Circuit Breakers for Data: Quality Monitoring That Stops Bad Loads Before They Wreck Analytics

Key takeaways

Implementation checklist