dbt Cloud Data Observability Features: What You Get and What Is Missing

dbt Cloud gives you four real observability features: source freshness checks, tests that fail a run, a lineage graph built from your DAG, and job run history with logs and artifacts. That covers whether your transformations ran and whether the rules you wrote passed. It does not cover tables outside your dbt project, anomalies nobody wrote a test for, schema drift in your sources, or column-level lineage into the BI layer. Those four gaps are why most dbt teams eventually add a separate observability layer.

Last updated July 2026.

What data observability features does dbt Cloud have?

More than people give it credit for, and it is worth being precise about them before deciding you need anything else.

Source freshness. You declare a freshness block on a source with warn_after and error_after thresholds, point it at a timestamp column via loaded_at_field, and dbt source freshness checks how stale each source is. This is genuine freshness monitoring on your ingestion boundary, it is free, and a surprising number of teams never turn it on.

Tests. Generic tests (unique, not_null, accepted_values, relationships) plus singular tests and packages like dbt-utils and dbt-expectations let you assert rules and fail the run when they break. With store_failures enabled, failing rows land in a table you can inspect.

Lineage. dbt builds a DAG from every ref() and source() call, so you get an accurate table-level lineage graph for free, kept current by construction because it is derived from the code rather than maintained separately.

Job run history and artifacts. dbt Cloud stores run results, timings, and logs for every job, so you can see which model failed, which got slower, and when. The manifest.json and run_results.json artifacts are also what most third-party tools read to understand your project.

Model contracts. Set enforced: true on a model's contract and dbt validates the output columns and types before materializing, failing the build rather than silently reshaping a table. This is real schema enforcement at the transformation boundary.

What dbt Cloud does not monitor

The gaps follow directly from how dbt works. dbt is a transformation tool that runs on a schedule, so its visibility starts where your dbt project starts and stops when the run ends.

Tables outside your dbt project. Warehouses accumulate tables from Fivetran syncs, reverse ETL, notebooks, stored procedures, and the analyst who built something in 2023 that finance now depends on. dbt knows nothing about any of them. In most warehouses this is not a rounding error: the modeled portion is often well under half the tables that people actually query.

Failures nobody asserted. This is the structural limit of testing. A test catches what someone thought to write down. The incidents that hurt are usually the ones nobody predicted: a vendor quietly dropping a field, a currency column switching from cents to dollars, a categorical value set gaining a sixth option, a join starting to fan out. Every one of those passes not_null and unique without complaint. Test coverage also decays; new models ship faster than tests get backfilled, and coverage tends to cluster on the tables an engineer once worried about rather than the ones quietly rotting.

Volume and distribution anomalies. dbt has no native concept of "this table normally gets 40,000 rows a day and got 900 today." You can hand-roll it with a singular test and a hard-coded threshold, but you are then maintaining thresholds by hand across every table, and they go stale the first time the business grows.

Silent success on stale data. A dbt run against a source that stopped loading three days ago succeeds cheerfully. Every model builds, every test passes, the dashboard updates with old numbers, and the run is green. Source freshness catches this only if you configured it on that specific source with a sensible threshold.

Column-level lineage. The dbt DAG is table-level. It tells you marts.revenue depends on staging.payments. It does not tell you that marts.revenue.mrr is computed from two specific columns and one CASE expression, which is exactly what you need during triage. It also stops at the edge of dbt, so it cannot show you the seven Looker dashboards downstream.

When does it make sense to use a data observability tool in addition to dbt?

Four signals, and if two or more are true it is usually already overdue.

Stakeholders find your incidents before you do. If the recurring pattern is a Slack message from finance asking why a number looks wrong, your detection layer is people. That is the clearest signal, and it is independent of how good your dbt project is.

A meaningful share of your warehouse is not modeled in dbt. If raw and third-party tables are load-bearing for real decisions, dbt cannot see the part of the warehouse where failures are most likely, because unmodeled tables are also the least tested.

Test maintenance is eating real time. Somewhere in the low hundreds of models, writing and repairing tests becomes a standing tax. When schema changes routinely break batches of tests and coverage still is not improving, automated baselines cost less than the rules.

Triage takes hours because impact is unknown. If a broken model means opening dashboards one by one to work out who is affected, you need column-level lineage into the BI layer.

Conversely, it is genuinely reasonable to wait. A team with 40 models, everything in dbt, source freshness configured, tests on the critical paths, and a dashboard nobody has complained about in six months does not need to buy anything yet. Turn on source freshness, add contracts to the models your executive dashboards read, and revisit at 150 models.

Which data observability tool is best for dbt?

It depends on how much of your warehouse lives inside dbt, which is the question that actually separates the options.

If your warehouse is essentially all dbt: Elementary. It installs as a dbt package, reads your artifacts, and reports on test results and anomalies inside your existing project. The open-source package is Apache-2.0 and genuinely good. Its cloud tiers are quote-only, and column-level lineage plus the ML monitors are cloud-only. It is dbt-bound by design, which is the strength and the ceiling.

If a lot sits outside dbt: a warehouse-native platform. Dataobservability, Monte Carlo, Bigeye, Sifflet, and Metaplane connect to the warehouse directly and monitor every table whether or not dbt built it, then read your dbt manifest for extra context. The practical difference among them is price transparency and scale. Only three of the twelve tools buyers commonly compare publish a price at all: Soda, Metaplane, and Dataobservability. Monte Carlo lists at $50,000 for a 12-month contract on AWS Marketplace and Bigeye at $45,000 a year for 100 tables, which sets the floor for the enterprise end of this market.

If your problem is regressions at merge time: Datafold. Value-level data diff on a pull request is a different job from production monitoring, and it is the right tool when your pain is "this refactor changed 3% of rows and nobody noticed."

Whatever you shortlist, trial it on your real warehouse for a week and count true positives per alert. A tool that fires 300 alerts nobody reads is worse than no tool, and no feature grid predicts that number.

Does dbt Cloud have anomaly detection?

Not natively, in the sense of learning a baseline per table and flagging deviations automatically. dbt tests are deterministic: a rule passes or fails. You can approximate anomaly detection with packages such as dbt-expectations, which offers checks like expecting a row count to be within a range of a previous period, or by writing singular tests that compare today's aggregates to a rolling average. Both work, and both leave you owning the thresholds. That is fine for ten critical tables and unmanageable across a thousand, which is the point where learned baselines start paying for themselves. Our guide to data anomaly detection covers how automatic thresholds are derived.

What is the difference between dbt tests and data observability?

dbt tests are assertions you write that run when the pipeline runs. Data observability is continuous measurement of production tables against baselines learned from history. Tests answer "did the rules I wrote pass on this run." Observability answers "is anything about this warehouse behaving differently than it normally does, including things I never thought about." Tests give precision on known risks and zero coverage on unknown ones; observability gives broad coverage and needs lineage and alert grouping to stay actionable. Neither replaces the other, which is why the common end state is dbt tests for business rules on modeled tables plus automated monitoring across everything. We compare the two in depth in dbt tests vs data observability.

How to get more observability out of dbt before buying anything

Five changes that cost nothing and close a real share of the gap:

Turn on source freshness everywhere. Add freshness blocks with warn_after and error_after to every source, and run dbt source freshness on a schedule separate from your main build so you learn about a stalled ingestion at 6am, not after a two-hour transformation job.

Enforce contracts on your top models. Set enforced: true on the contracts for models your executive dashboards read. It fails the build on a schema change instead of quietly reshaping a table, in the same way a deployment pipeline blocks a bad release before it reaches production. If you are formalizing this across teams, our guide to data contracts covers the wider agreement, including SLAs and ownership.

Enable store_failures. Debugging a failed test is far faster when you can query the offending rows instead of re-deriving them.

Add freshness and row-count tests on the tables nobody models. Even if a table is not in dbt, you can add it as a source and test it. This is the cheapest way to cover unmodeled tables.

Alert on warn, not just error. Teams set warning thresholds and then never surface them anywhere, which means the early signal is captured and discarded.

Do all five and you will catch a good share of what a platform would catch. What stays uncovered is anomaly detection without thresholds, schema drift on sources outside your control, and column-level impact analysis. That residue is the actual buying decision.

Frequently asked questions

What data observability features does dbt Cloud have?

dbt Cloud provides source freshness checks with configurable warn and error thresholds, generic and singular tests that fail a run, model contracts that enforce output columns and types before materialization, a table-level lineage DAG built from ref and source calls, and job run history with logs and artifacts. Together these cover whether transformations ran and whether the rules you wrote passed.

When does it make sense to use a data observability tool in addition to dbt?

When stakeholders find incidents before you do, when a meaningful share of your warehouse is not modeled in dbt, when maintaining tests has become a standing time cost, or when triage takes hours because you cannot see downstream impact. If two or more of those are true, the observability layer usually pays for itself in avoided incidents within a quarter.

Which data observability tool is best for dbt?

If your warehouse is almost entirely modeled in dbt, Elementary fits best because it installs as a dbt package and reports inside your existing project. If a significant portion sits outside dbt, a warehouse-native platform such as Dataobservability, Monte Carlo, Bigeye, or Metaplane is a better fit because it monitors every table regardless of origin while still reading your dbt manifest for context.

Does dbt have anomaly detection?

Not natively. dbt tests are deterministic assertions rather than learned baselines. You can approximate anomaly detection with dbt-expectations checks or singular tests comparing aggregates to a rolling average, but you own and maintain every threshold. That is workable on a handful of critical tables and impractical across a whole warehouse.

Does dbt Cloud have column-level lineage?

The dbt DAG is table-level: it records that one model depends on another, not that a specific column is computed from specific upstream columns. Column-level lineage is generated by parsing your compiled SQL, which several third-party tools do on top of the dbt manifest. Our guide to column-level lineage explains how it is derived and why incident triage depends on it.

Can dbt tests replace a data observability platform?

On a small, fully modeled warehouse with disciplined test coverage, close to it. At scale they diverge, because tests only catch failures somebody anticipated and only cover tables inside your project. Most teams keep dbt tests for business rules and add automated monitoring for freshness, volume, schema drift, and distribution across every table.

Is dbt Cloud source freshness the same as a freshness monitor?

It is the same idea with manual configuration. dbt source freshness compares a timestamp column against thresholds you set per source, so it works well where you configured it and not at all where you did not. A freshness monitor in an observability platform learns each table's normal load pattern from history and applies to every table automatically, including ones you never touched.