Integration
dbt Data Observability That Reads Your Manifest
Point us at your dbt project and we generate monitors and lineage from your manifest, adding always-on coverage that dbt tests alone cannot give you.
14-day trial, no credit card, read-only connection
Alerted #data-eng 0.8s ago.
Downstream impact · consumers at risk
In one paragraph
dbt data observability extends dbt tests with always-on monitoring. Dataobservability reads your dbt manifest to auto-generate freshness, volume, schema, and anomaly monitors on your models and sources, and builds column-level lineage from your project, so you catch breakages between runs and the failures you never wrote a test for.
Side by side
dbt observability options compared
Swipe to see all columns →
| Option | What it catches | When it runs | Coverage |
|---|---|---|---|
| dbt tests (generic and singular) | The specific assertions you wrote: not null, unique, accepted values, relationships | Only during a dbt run, as part of the DAG | Only the models and columns somebody wrote a test for |
| dbt model contracts | Column names, data types, and constraints on a model output, before it materializes | At build time, in the run and in CI | Only dbt models with an enforced contract block |
| dbt Cloud job alerts | A job that failed, errored, or ran long | On job completion | Job status only, not the correctness of the data the job produced |
| dbt source freshness | A source table whose loaded_at column is older than the warn or error threshold | When you run dbt source freshness | Only sources with a freshness block and a usable timestamp column |
| Elementary | dbt test results, anomaly monitors, and lineage, built as a dbt package | Alongside dbt runs; cloud tier adds continuous monitors | dbt only by design, so nothing outside the project |
| Data observability platform (Dataobservability) | Freshness, volume, schema, and distribution anomalies on every model and source, plus the tables dbt never touches | Continuously, between runs and independent of them | The whole warehouse, with column level lineage through dbt into BI |
Summarized in good faith from public documentation, August 2026. Verify current behavior and terms with the vendor.
Why it fits
Analytics engineering teams who live in dbt and want coverage beyond hand-written tests.
Auto-monitors from the manifest
Every model and source gets monitored without you writing a single YAML test.
Beyond dbt tests
dbt tests check rules at run time. We add continuous, ML-tuned monitoring around the clock.
Lineage from your project
Your ref() graph becomes column-level lineage with downstream BI impact.
Where dbt tests stop and observability starts
dbt tests are good at what they do, and what they do is narrow in three specific ways worth naming. They only check what somebody wrote down. Every real dbt project has a handful of heavily tested models and a long tail with a not_null on the primary key and nothing else, and incidents come from the long tail. They only run when dbt runs. If your job runs at 6am and a source stops loading at 9am, dbt is not going to notice until tomorrow morning, and in the meantime every dashboard reads yesterday's numbers with today's date on them. And they are binary assertions, not baselines: a test that a revenue column is not null passes happily when revenue drops by 90 percent, because the values are all present, they are just wrong. Observability covers those three gaps rather than replacing tests. Monitors are generated for every model and source rather than written per column, so coverage does not depend on discipline. They run on their own schedule, so a failure between runs surfaces in minutes. And they compare against learned history rather than a rule, so a volume that fell from 40,000 rows to 1,600 raises an incident even though no assertion was violated. The pattern that works in practice is to keep dbt tests for the business rules you actually can articulate, gate pull requests on them, and let automatic monitoring handle time, volume, shape, and everything nobody thought to write down.
What the Fivetran and dbt Labs merger means for dbt observability
Fivetran and dbt Labs completed their merger on June 1, 2026, roughly eight months after announcing it in October 2025. George Fraser leads the combined company and Tristan Handy is co-founder and president. If you run dbt in production, a few things follow. The transformation layer and the ingestion layer now come from one vendor, which is convenient for procurement and worth watching for anyone who deliberately kept ingestion and transformation independent. dbt Core v2.0 arrived carrying the open source dbt Fusion engine, a Rust rewrite released under Apache 2.0 that parses and compiles large projects dramatically faster than the Python implementation. dbt State adds selective processing so runs skip assets that did not change. Those are genuine improvements, and none of them changes the observability picture. Faster parsing does not tell you a source stopped loading. Selective processing means fewer models rebuild, which is cheaper and also means fewer tests execute on any given run, so the between runs gap gets slightly wider rather than narrower. The merger does raise one strategic question for buyers: Fivetran also became the steward of Great Expectations in May 2026, so a single vendor now sits across ingestion, transformation, and an open source quality framework. Whether you want your data quality verification supplied by the same company that supplies the pipelines it is verifying is a genuine independence question, and it is the same question people ask about relying on Snowflake to grade Snowflake.
Column level lineage from your dbt project
A dbt DAG already knows a lot about how your data is connected, and most teams only use a fraction of it. The manifest records every model, every source, every ref and every source call, plus the compiled SQL for each node. That compiled SQL is where column level lineage comes from: parse it and you can trace that orders.net_revenue is derived from stg_orders.gross_amount and stg_discounts.amount, rather than only knowing that one model depends on another. The difference matters during an incident. Model level lineage answers which models sit downstream, which on a mature project is often forty of them, and the honest response to a forty model blast radius is to check them all by hand or to ignore it. Column level lineage answers which downstream fields actually derive from the column that broke, and that list is usually two or three, with a specific dashboard attached to each. Dataobservability reads the manifest to build that graph automatically, extends it past the last dbt model into the BI layer, and attaches it to every incident. It also covers what the manifest cannot see: raw landing tables loaded by ingestion tools before dbt ever touches them, and any table in the warehouse that is not part of your project, which is where a surprising share of production reporting quietly lives.
Monitoring dbt Cloud jobs versus monitoring the data
dbt Cloud will tell you when a job fails, errors, times out, or takes longer than usual, and you should absolutely have those notifications wired up. They answer a question about your orchestration: did the thing run. The question they cannot answer is whether the data is right, and those two come apart more often than teams expect. A job succeeds while an upstream source silently returned an empty response, so the incremental model appends nothing and every downstream number freezes at yesterday's value with a green check mark next to it. A job succeeds after someone merged a change that redefined how a segment is calculated, so revenue by segment shifts fifteen percent and no test fails because no test encoded the old definition. A job succeeds on schedule while the Fivetran connector that feeds it has been paused since Friday. In each case the pipeline status page is green and the numbers are wrong, which is the worst combination because it means nobody is looking. The practical setup is both layers: dbt Cloud alerts for job health, and continuous data monitoring on freshness, volume, schema, and distribution for whether the output is trustworthy. Wire both into the same incident channel with the downstream impact attached, so whoever is on call sees one thread that says which tables broke, which dashboards read them, and whether the job even ran.
Frequently asked questions
What is dbt data observability?
dbt data observability means continuously monitoring the models and sources in your dbt project for freshness, volume, schema changes, and distribution anomalies, and building column level lineage from the project graph. It runs independently of dbt, so problems that appear between runs surface immediately, and it covers models nobody wrote tests for.
Are dbt tests enough for data quality?
For the rules you can articulate, yes. For coverage, no. dbt tests only check assertions someone wrote, only run when dbt runs, and only pass or fail against a fixed rule. That leaves three gaps: untested models, failures that happen between runs, and values that are technically valid but statistically wrong, such as a table that loaded 1,600 rows instead of 40,000.
How do I monitor dbt in production?
Use two layers. Wire dbt Cloud job notifications so you know when a run failed, and run dbt source freshness on your sources. Then add continuous monitoring on the warehouse itself for freshness, volume, schema, and distribution, so a failure that happens between scheduled runs, or in a table dbt does not manage, still produces an alert with downstream impact attached.
Does dbt have column level lineage?
dbt Cloud shows a model level lineage graph from your ref and source calls, and the Explore interface adds column level lineage on paid plans. dbt Core on its own produces a manifest containing compiled SQL, which is the raw material for column level lineage but not a rendered graph. Dataobservability parses that manifest to build column level lineage and continues it past dbt into BI dashboards.
How do I visualize the data lineage created by dbt?
dbt docs generate builds a static site with an interactive DAG from your manifest, and dbt Cloud renders the same graph in Explore. Both stop at the boundaries of the project. To see the full path, from the raw landing table an ingestion tool wrote through your dbt models to the specific dashboard tile a business user opens, you need lineage that reads the manifest and the warehouse and the BI layer together.
What is the dbt Fusion engine?
dbt Fusion is a Rust rewrite of the dbt engine, released as open source under Apache 2.0 as part of dbt Core v2.0. It parses and compiles large projects substantially faster than the Python implementation and understands SQL well enough to catch errors before a run. It changes build performance and developer experience, not what happens to your data between runs.
Did Fivetran and dbt Labs merge?
Yes. The merger was announced on October 13, 2025 and completed on June 1, 2026, with George Fraser as chief executive of the combined company and dbt Labs co-founder Tristan Handy as president. Fivetran had also become the steward of the Great Expectations open source project in May 2026, so ingestion, transformation, and an open source data quality framework now sit with one vendor.
What is the difference between Elementary and a data observability platform?
Elementary is a dbt package: it collects dbt test results, adds anomaly monitors, and renders a report, all inside your dbt project. That makes it a natural fit if everything you care about is modeled in dbt, and it is genuinely good at that. A platform monitors the warehouse independently of dbt, so it also covers raw landing tables, tables outside the project, and the hours between runs when dbt is not executing at all.
Live on day one
Connect your warehouse and watch monitors generate across every table. Transparent pricing, no credit card.