Skip to main content
Pipeline metrics for dbt are in active development. This page describes the planned model and is subject to change before release.
A dbt pipeline isn’t a single asset — it’s three connected layers: the models that transform data, the tests that validate it, and the jobs that orchestrate the runs. PRIZM tracks metrics at all three levels, and — like every other metric in PRIZM — each one belongs to one of the same contexts you already use for tables and columns: Operational, Performance, or Business. Pipeline health isn’t a separate system; it’s the same model, applied one layer earlier in the chain.

​
Three levels of pipeline activity

Models

Is this model running on schedule, how long does it take, and does the volume it produces look normal?

Tests

Are this model’s dbt tests passing, and how long does the test suite take to run?

Jobs

Is the job orchestrating these runs completing on time and within its expected duration?

​
Model metrics

We considered a Run Success Rate metric (% of successful runs over a rolling window) but left it out. A model run is either a hard pass or a hard fail — folding that into a rolling percentage buries a real failure inside a dashboard number instead of surfacing it as the alert it should be. Freshness plus the run’s own pass/fail status already covers this more directly.

​
dbt test metrics

Test alerts aren’t turned on automatically. Because test volume and strictness vary a lot by team, alerting on dbt test pass/fail is configured explicitly at the connector level — with a bulk-edit option to enable or disable it across every test at once — rather than defaulting to on. Neither test metric has automated anomaly detection; both are surfaced as insights, with automated or manual anomaly detection and alerting available as an opt-in.

​
Job metrics

We deliberately left Job Success Rate out of this list. A dbt job failure is a hard operational event, not a gradual trend — the right response is an immediate alert and remediation, not a rolling “95% success over 7 days” figure that quietly tolerates roughly one failure a week.

​
Where you see it

Every pipeline metric opens to the same detail view as any other PRIZM metric: an Overview tab with an AI-generated summary of what’s being measured, a Results panel showing the current anomaly status, an anomaly distribution chart (current vs. baseline, with drift and outlier percentages), and a table of recent anomalies with their expected range, actual value, and priority — plus Timeline, Audit tabs alongside it.

​
How pipeline metrics propagate

  • Where metrics run. Business metrics can run automatically the moment a model finishes — configured once, at the connector level. Every other pipeline metric (freshness, execution time, rows affected) is configured per table, triggered off that table’s own freshness event.
  • Failure cascades through the chain. Pipelines move in layers — tables from Raw → Bronze → Silver → Gold, fed by models from Source → Bronze → Silver → Gold. When a model’s execution fails, PRIZM checks the freshness of the table it feeds, on that table’s own schedule. Root cause analysis on the resulting table alert surfaces the model that caused it — even if that model didn’t have alerting turned on itself.
  • Alerts cluster by root cause. Every alert traced back to the same underlying issue is grouped into a single cluster. Resolve the root cause, and every alert in that cluster resolves with it, rather than needing to be closed one at a time.
  • Deprecation follows the source. If a model is deprecated upstream, PRIZM marks the corresponding downstream asset as deprecated too, so the catalog doesn’t keep surfacing dead ends.
Pipeline metrics don’t introduce a new system — they slot model, test, and job checks into the same Operational, Performance, and Business contexts used everywhere else in PRIZM, so a dbt job shows up in the same Alerts feed and trust-scoring model as any other asset.