Data observability platforms automatically detect anomalies in data pipelines — unexpected row count drops, freshness failures, schema changes, and distribution shifts — before business users notice. This guide covers the leading tools, what each does well, and how to decide whether to buy a platform or build observability on top of dbt and open-source tooling.
Data observability is the practice of automatically monitoring data pipelines for the anomalies that indicate quality problems — row count drops, freshness failures, distribution shifts, schema changes, and referential integrity violations. Without observability, data quality problems are detected by business users noticing wrong numbers in reports. With observability, problems are detected by automated systems before they reach consumers.
The tooling landscape has developed rapidly. This guide covers the leading approaches — enterprise platforms, open-source tools, and custom builds — and the decision framework for choosing between them.
What Data Observability Covers
Data observability monitors across five dimensions commonly called the "five pillars":
**Freshness:** Is data arriving on time? A daily fact table that did not update overnight has a freshness problem. Freshness monitoring tracks when each table was last updated and alerts when the elapsed time since the last update exceeds defined thresholds.
**Volume:** Is the amount of data within expected ranges? A table that normally receives 100,000 rows per day receiving 1,000 rows is a volume anomaly indicating an upstream failure. Volume monitoring tracks row counts and alerts on unusual deviations from historical patterns.
**Distribution:** Are column value distributions within expected patterns? If a revenue column that has historically ranged from $10 to $10,000 suddenly has values of $0.01 or $100,000, that is a distribution anomaly. Automated distribution monitoring uses historical statistics to flag unusual values.
**Schema:** Did the schema change unexpectedly? Column additions, column removals, type changes, and renamed columns can break downstream dependencies. Schema monitoring detects changes and alerts relevant stakeholders.
**Lineage:** When a problem is detected, what does it affect downstream? And what upstream sources fed into it? Column-level lineage lets you trace a metric anomaly back to its root cause and understand which downstream reports are affected.
Enterprise Platforms
### Monte Carlo
Monte Carlo is the category-defining enterprise data observability platform. It connects to your data warehouse and automatically:
- Learns the baseline statistical distribution for every table and column (volume, freshness, null rates, unique value counts, numeric distributions)
- Alerts when metrics deviate from learned baselines beyond configurable thresholds
- Detects schema changes automatically
- Builds end-to-end lineage from ingestion through BI tools (Fivetran, dbt, Snowflake, Tableau, Looker, all integrated)
- Provides an incident management workflow for investigating and resolving data quality issues
Monte Carlo's automation — the fact that it learns baselines and detects anomalies without requiring manual test configuration — is its primary differentiator. You do not need to write tests; Monte Carlo infers what "normal" looks like and alerts when reality departs from it.
The cost is significant: Monte Carlo pricing is typically in the range of $50,000–$200,000+ per year depending on data volume and feature tier. Appropriate for enterprises with mature data organisations and a genuine data reliability programme.
### Anomalo
Anomalo focuses specifically on automated anomaly detection — the distribution and volume monitoring dimension. Like Monte Carlo, it learns baselines and detects deviations. It positions as a more focused alternative to Monte Carlo with lower cost for organisations whose primary need is anomaly detection rather than the full observability suite.
### Acceldata
Acceldata provides data observability with a stronger focus on data engineering pipelines and infrastructure performance — not just data content quality. Useful for organisations monitoring Spark and other processing pipelines alongside data quality.
Open-Source: Elementary
Elementary is an open-source data observability tool built natively on dbt. It is the most popular open-source observability solution for dbt users.
What Elementary provides:
**Test results tracking:** Elementary stores dbt test results in your data warehouse and provides a data observability report showing test pass/fail rates over time, which tables are improving or degrading, and test coverage metrics.
**Anomaly detection tests:** Elementary extends dbt with custom generic tests for anomaly detection — row count anomalies, freshness anomalies, null rate anomalies, distribution anomalies. These tests use historical data in your warehouse to set adaptive thresholds.
**Data lineage visualisation:** Elementary generates a lineage graph from dbt's manifest and test results, showing data flow through your pipeline.
**Alerting:** Elementary can send test failure and anomaly alerts to Slack, PagerDuty, or Teams.
Elementary runs entirely within your existing dbt and warehouse infrastructure. There is no external SaaS dependency, no data leaving your environment. The community edition is free; Elementary Cloud (managed hosting of the Elementary UI) has a paid tier.
**The limitation:** Elementary requires manual test configuration — you choose which tests to apply to which tables. The automated baseline learning of Monte Carlo does not exist in Elementary; you define the anomaly thresholds explicitly. This requires more setup time and expertise but gives you full control over what is monitored.
Custom Build on dbt Tests
For teams already using dbt, building observability on top of dbt's native test infrastructure is the lowest-cost starting point.
The approach:
1. Write not_null, unique, relationships, and accepted_values tests for critical tables (data quality testing — covered separately in the dbt testing guide)
2. Write singular tests for business logic assertions
3. Add dbt-expectations package for row count range tests and distribution tests
4. Store test results in a monitoring table (Elementary automates this; a custom implementation can do it with a dbt operation)
5. Build a simple monitoring dashboard from the test results table — showing test pass rates per table, trend over time, and current failing tests
This approach costs approximately zero in tooling (dbt Core is free, dbt-expectations is free) and requires initial setup time plus ongoing test maintenance. It covers the quality testing dimension well but does not provide automated baseline learning for anomaly detection or end-to-end lineage.
The Build vs Buy Decision
The decision framework:
Buy Monte Carlo or equivalent if:
- Your organisation has 5+ people dedicated to data quality and reliability
- The cost of data quality failures (user trust degradation, analyst time investigating, business decision mistakes) is quantifiable and significant
- You need automated anomaly detection without manual test configuration
- End-to-end lineage from ingestion through BI is required for root cause analysis
Use Elementary (open source) if:
- You are already on dbt and want observability native to your existing tooling
- You have the engineering capacity to configure and maintain the tests
- Budget for enterprise observability is not available
- You are building toward a full observability programme and want to start with a foundation you control
Build on dbt tests if:
- Your team is small (under 3 data engineers) and the overhead of a separate observability tool is not justified
- Your pipeline is simple enough that the five pillars can be covered with dbt tests and a simple monitoring dashboard
- You want to understand data quality before committing to an observability platform
For most mid-market data teams, Elementary is the practical starting point: open source, dbt-native, meaningful observability without SaaS cost. The upgrade path to Monte Carlo exists when the organisation's data reliability programme justifies the investment.
What Observability Does Not Replace
Data observability detects anomalies; it does not prevent them. A Monte Carlo alert firing because a table lost 90% of its rows tells you there is a problem — it does not fix the broken pipeline or prevent the downstream reports from showing wrong data.
Observability is most valuable when paired with clear ownership (who is responsible for investigating and resolving each alert), fast resolution processes (a team that can turn around a quality incident within hours), and a communication protocol (how are affected report users notified).
Observability tooling without the operational process around it produces alert fatigue — too many alerts, no clear owners, nobody acting on them — which is worse than no alerts.
Our data engineering consulting practice designs data quality and observability programmes — contact us to discuss data observability for your environment.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →