dbt-data-reliability turns dbt artifacts into tables you can query
This dbt package captures metadata, artifacts, and test results so you can detect anomalies, monitor data quality, and build metadata tables. It powers Elementary OSS and feeds the wider context layer used by Elementary Cloud’s full Data & AI Control Plane.
At a glance
- What is it?
- The dbt-data-reliability package is a dbt package from the Elementary team that loads dbt artifacts and run results into your warehouse as structured tables and ships anomaly detection tests that run like native dbt tests. It works on its own and also acts as the data layer under Elementary OSS and Elementary Cloud.
- Who is it for?
- dbt-data-reliability suits a dbt shop that already has models, tests and a warehouse and wants the run metadata queryable next to the data, and it does not suit a team without dbt or without a warehouse to hold the Elementary tables. Before you add it, read the quickstart page linked from the README and check that your dbt_project.yml on-run-end hook area can take the package's hook, because the collection step is a hook and not a separate job you can run later.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem is that dbt's run metadata lives outside the warehouse
dbt already knows a great deal about your pipeline. It knows which models exist, which tests ran, which sources are exposed, how long each model took, whether a test passed. That information ends up in artifacts, and artifacts are files on a runner that get overwritten by the next run.
The consequence is familiar to anyone who has operated a dbt project. When a stakeholder asks why a number changed, the answer lives in `target/` on somebody's CI machine, and reconstructing it means digging through run logs. The alternative is to copy the artifacts into the warehouse yourself, which is a small job that is easy to do badly and impossible to leave unmaintained.
dbt-data-reliability is a dbt package that does that copying as part of the run. Its description says it captures metadata, artifacts and test results so you can detect anomalies, monitor data quality and build metadata tables, that it powers Elementary OSS, and that it feeds the wider context layer used by Elementary Cloud's Data and AI Control Plane. The audience is a dbt shop that wants observability to live in the same place as the data, queried with the same SQL skills the team already has.
Collection happens in an on-run-end hook, not in a separate job
The mechanism is worth being precise about, because it determines when the data lands and what you have to trust. The package uses dbt's on-run-end hook, and it automatically parses your dbt artifacts and run results and loads them as structured tables into your warehouse. There is no separate collector to schedule, and no daemon to operate. The tables are populated as a side effect of a normal dbt run.
That has a pleasant property and a sharp edge. The pleasant property is that there is nothing extra to remember, so the metadata is always there. The edge is that the hook runs at the end of a dbt invocation, so the state captured is the state of that invocation, and any table query you run afterwards is looking at the warehouse as of the last completed run rather than at a live system.
The repository layout supports this reading. The package is a dbt project with the expected structure: `dbt_project.yml` at the root, `packages.yml` for its dependencies, and then `macros/`, `models/`, `tests/`, `snapshots/`, `analyses/` and `data/` directories holding the implementation. There is also an `integration_tests/` directory, a `dev-requirements.txt`, a `.pre-commit-config.yaml` and a `.flake8` configuration, so the package is linted and tested like a piece of Python-flavoured software rather than a loose folder of SQL.
Two table families: what exists, and what happened
The Elementary Tables side splits into two families, and the split is the useful mental model for querying them.
The metadata tables describe the shape of the project: models, tests, sources, exposures, columns, seeds, snapshots, and more. They are a catalogue of what your warehouse contains and how it is connected. The run results tables describe what happened during a run: invocations, model run results, test results, source freshness, and job-level outcomes. They are a log of the last execution, and they are what you join against when a test failed or a source went stale.
The README is explicit that these tables are the backbone of any observability setup, and that they enable alerts, reports and lineage when connected to Elementary OSS or Cloud. That last clause matters. On their own the tables are queryable metadata, and you can write your own monitoring SQL against them, but the alerting, reporting and lineage surfaces are supplied by the tools that sit on top.
A practical note for adoption: because the metadata and the run results live in the same warehouse as your models, you can join a failing test back to the rows it examined without exporting anything. That is the concrete advantage over reading artifacts out of a CI bucket, and it is the reason the on-run-end hook design is worth the coupling it creates.
Elementary Tests are dbt tests, which changes where they run
The second component is a suite of anomaly detection and data quality tests. The important detail is how they run: like native dbt tests, with no separate tooling. A test that behaves like a dbt test runs in the same place, on the same schedule, with the same result reporting, which means it fails the same way your other tests fail and appears in the same run results.
The coverage described in the README spans volume, freshness, column distributions, schema changes, and AI-powered validation for structured and unstructured data. Volume and freshness are the classic cases a team writes by hand, and a column distribution check such as a range or a uniqueness rule is where the anomaly detection earns its keep, because the expectation is derived from history rather than declared by a human. Schema change detection covers the case where a source quietly drops a column and downstream models keep returning nulls.
The AI-powered validation part is the piece to treat carefully. It is described as covering structured and unstructured data, which is a broader claim than a dbt test on a table can usually make, and the README gives no detail on how it is configured or what it costs. If AI-based validation is the reason you are evaluating the package, dig into the linked documentation for the test list before you commit, because the repository README is a summary rather than a specification.
Metric stability is the test that catches restated history
One test deserves a section of its own, because it addresses a failure mode that ordinary dbt tests do not. Metric stability detects restatements of settled historical aggregates within a configured observation window.
Read that carefully, because it is a narrow and valuable thing. Most data tests ask whether today's data looks plausible. This one asks whether a number that was already settled and reported has changed since it was reported. Finance and analytics teams hit this when a late arriving fact or a corrected upstream record rewrites last quarter's revenue after the quarter was closed and the number went to a board slide. Nothing is broken, no test fails, and the discrepancy between what was said and what is now in the warehouse is invisible until someone reconciles it by hand.
The observation window is the parameter that makes it practical. Configured wide, the test flags any restatement in the recent past, which is noisy if restatements are normal in your pipeline. Configured tight, it watches the period right after close, which is where a restatement is most damaging. The README does not give the default value or an example configuration for the window, so this is a setting to look up in the documentation rather than something to infer from the code, and the test is worth understanding in depth before you let it page anyone.
Standalone package, Elementary OSS CLI, or Elementary Cloud
The README states that the dbt package works standalone and integrates with both Elementary OSS and Elementary Cloud. Those are three levels of commitment, and the difference between them is where the real decision sits.
Standalone means you install the package, get the tables in your warehouse and the tests running in dbt, and build your own alerting SQL on top. Nothing else is required, and nothing else is provided. The work lands on whoever owns monitoring.
Elementary OSS is described as a self-hosted CLI for alerts and a local observability report, so it is the layer that consumes those warehouse tables and turns them into notifications and a report you can look at, while staying on infrastructure you control.
Elementary Cloud is the hosted option, described as a full Data and AI Control Plane with automated ML monitoring, column-level lineage from ingestion to BI and AI assets, a built-in catalog, and AI agents for reliability workflows. It is where the lineage, the catalogue and the machine learning monitoring come from, and it is a commercial decision rather than a technical one.
The README also carries the claim that the package is ranked among the top 5 dbt packages and is supported by a community of thousands. That is the project's own marketing statement, and it is not something to weigh as evidence. Judge the package on whether the tables and the tests do what your monitoring needs, since the open source part is what you would be running either way.
Getting started means the quickstart docs, not a package manager
There is no install command in the README, and that is not an omission so much as a fact about dbt packages. The installation route for this kind of package is the dbt package mechanism, and the README points you at the quickstart page for the package at docs.elementary-data.com/data-tests/dbt/quickstart-package, with a separate documentation page listing the package models.
The repository itself tells you what a working copy looks like. The root has `packages.yml`, which is where a dbt project declares its package dependencies, and `dbt_project.yml`, which is where the project declares its models, tests and configuration. The `macros/` directory holds the macros the package contributes, `models/` holds the Elementary tables themselves, `tests/` holds the test definitions, and `snapshots/` holds snapshot configurations, which is how the package keeps the state it compares against on a run over time.
That last point is the practical one to check first. Snapshot-based comparison means the package needs somewhere to persist state, and where that state lives, and how long it is kept, decides whether your history is deep enough for the anomaly tests to have anything to detect. The README does not document that, so the questions to ask of the documentation are about the snapshot storage and its retention.
On maintenance, the project is Apache-2.0 licensed with a `LICENSE` file at the root and a `SECURITY.md`, and the last push to the repository was on 2026-10-13. The release list shows 0.25.1 on 2026-07-07, 0.26.0 on 2026-09-08 and 0.26.1 on 2026-10-11, so patch releases arrive on their own and a major bump in the minor version number is a signal to read the release notes rather than a routine upgrade. Support is offered through a Slack community and GitHub issues on the Elementary repository, which is worth knowing because this package is maintained alongside the larger Elementary project rather than on its own.
Editorial conclusion
dbt-data-reliability suits a dbt shop that already has models, tests and a warehouse and wants the run metadata queryable next to the data, and it does not suit a team without dbt or without a warehouse to hold the Elementary tables. Before you add it, read the quickstart page linked from the README and check that your dbt_project.yml on-run-end hook area can take the package's hook, because the collection step is a hook and not a separate job you can run later.
Frequently asked questions
What does the dbt-data-reliability package do?
It loads dbt artifacts and run results into your warehouse as structured tables, covering metadata such as models, tests, sources, exposures, columns, seeds and snapshots, plus run results such as invocations, model run results, test results and source freshness. It also ships anomaly detection and data quality tests that run like native dbt tests.
How does dbt-data-reliability collect the data?
The package uses dbt's on-run-end hook, so it parses the artifacts and run results of a normal dbt invocation and loads them into the warehouse automatically. There is no separate collector to schedule, and the tables reflect the last completed run.
What is the metric stability test in dbt-data-reliability?
It detects restatements of settled historical aggregates within a configured observation window, so a number that was already reported and later rewritten is caught. The README does not state the default window, so the configuration has to be looked up in the documentation.
Do I need Elementary OSS or Cloud to use dbt-data-reliability?
No. The README says the dbt package works standalone, and it integrates with Elementary OSS, a self-hosted CLI for alerts and a local observability report, and with Elementary Cloud, the hosted control plane that adds lineage, a catalog and ML monitoring.
How do I install dbt-data-reliability?
The README does not give a shell command for it, because it is installed through the dbt package mechanism rather than a package manager, with the dependency declared in `packages.yml`. The README points to the quickstart page in the Elementary documentation, and the repository root also holds `dbt_project.yml`, `macros/`, `models/`, `tests/` and `snapshots/`.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/elementary-data-dbt-data-reliability)Was this useful?