Reliability you can prove
Every run leaves results, logs and freshness behind, and CI surfaces failures early, so you can show the pipeline is healthy.
No history. No freshness. You hear about a break from an angry email.
When someone asks if the data is healthy today, you answer with a run history, not a hope.
You cannot manage what you cannot see. In a lot of data estates, the honest answer to “is the pipeline healthy right now?” is a shrug. There is no run history, no freshness signal, no record of what passed last night. The first sign that something broke is an angry email from someone who trusted a dashboard that was quietly stale.
That is an expensive way to find out. By the time the message lands, the bad number has already been in a meeting, a forecast or a board pack. The cost is not just the fix. It is the credibility of every other number you publish.
What dbt does about it
Every dbt build leaves evidence behind. Each run produces structured results: which models succeeded, how many rows they wrote, how long each took, and the full log of what happened. Declared sources carry freshness checks, so you know not just that a model ran, but that the data underneath it is current. Nothing is hidden in someone’s head.
That evidence turns into a guardrail when you put it in CI. Before a change merges, your continuous integration runs the build and the tests against it. A broken model or a failing check stops the change at review, so reliability is enforced on the way in, not audited after the fact. This pairs naturally with the checks described in catch bad data before the business sees it: the tests catch the bad record, the run history proves the catch happened.
What it looks like
A scheduled build runs overnight. One source is twelve hours stale because an upstream load stalled. dbt’s freshness check flags it, the run is marked failed with the exact source named, and an alert lands in your team’s channel before anyone opens a report. By the time the business is awake, the note already reads “handled, here is what and why.”
Over weeks, the run history becomes an asset in its own right: durations you can trend, failures you can count, a freshness record you can show an auditor. Reliability stops being a claim and becomes something you can demonstrate. dbt’s run visibility documents exactly what each build records.
How we think about it
Reliability you can prove beats reliability you assert. We wire run results, source freshness and CI into every dbt project we build, on Microsoft Fabric or Databricks alike, and route failures to where your team will see them first. The goal is simple: when someone asks whether the data is trustworthy today, you answer with a run history, not a hope.
Reliability you can prove, in short.
Where do run results live?
dbt writes a structured artifact for every build, including each model's status, row counts and timing, plus full logs. Those artifacts are yours: keep them in your warehouse, your CI logs or an observability tool. Either way you get a queryable history of every run, not a memory of the last one.
Does this need a paid product?
No. Run results, logs and source freshness are part of open-source dbt Core and cost nothing. You schedule builds with the orchestrator you already run, Fabric pipelines or Databricks Jobs, and read the artifacts from there. A managed service can add a hosted UI and alerting on top, but the reliability evidence itself is built in.
How does CI fit in?
CI runs your build and tests against every proposed change before it merges. A failing test or a broken model stops the change at review, so a problem is caught in a pull request rather than discovered in production. It is the same guardrail your application teams already trust, applied to data.
Can we alert into Teams or email?
Yes. Because every run ends in a clear pass or fail with structured detail, your orchestrator can route that result anywhere: a Teams channel, an email, or an on-call tool. The alert carries which model failed and why, so the first person to know is your team, not a business user.
Keep exploring
Catch bad data before the business sees it
Tests run on every build and fail loudly, so wrong records are caught at the source, not discovered in a board report.
A data catalog everyone trusts
dbt generates a searchable docs site with descriptions, owners, types and tests, built from the code that runs so it never drifts.
Data lineage you can follow
dbt maps every column from raw source to dashboard automatically, so you can trace where any number came from and see what a change will break before you make it.
Want this for your data?
If this is how you want your team to work, we should talk.