> ## Documentation Index > Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt > Use this file to discover all available pages before exploring further. # Pipeline Metric > PRIZM extends its Operational, Performance, and Business metric contexts to pipelines — tracking model runs, test outcomes, and job executions so pipeline problems surface as alerts, not just numbers on a dashboard. 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](/concepts/metrics) 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 Is this model running on schedule, how long does it take, and does the volume it produces look normal? Are this model's dbt tests passing, and how long does the test suite take to run? Is the job orchestrating these runs completing on time and within its expected duration? ## Model metrics | Metric | Context · Category | Default? | What it answers | Example alert | | -------------- | -------------------------------------- | ------------------- | ---------------------------------------------------------------- | ---------------------------------------------- | | Freshness | Operational · Availability (Freshness) | Default — always on | Has this model run within its expected window? | No run in the last 24 hours | | Execution time | Performance · Usage (Activity) | Configurable | How long did the model take to run? | Run took longer than 10 minutes | | Rows affected | Operational · Availability (Volume) | Configurable | How many rows did the last run touch, and does that look normal? | Anomaly detected against historical run volume | 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 | Metric | Context · Category | What it answers | Example alert | | ------------------- | ----------------------------------- | ----------------------------------------------------- | --------------------------------------- | | Test success rate | Business · Conditional (Validation) | What share of this model's dbt tests passed recently? | Failure rate above 10% | | Test execution time | Performance · Usage (Activity) | How long is the test suite taking to run? | A single test took longer than 1 minute | 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 | Metric | Context · Category | What it answers | Example alert | | ----------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | Job duration | Performance · Usage (Activity) | How long did the entire dbt job take end to end? | Job ran longer than 15 minutes | | Job run frequency | Operational · Availability (Freshness) | Is this job still running on its expected cadence? | No run in the last 24 hours | | Execution status | Did the last pipeline run succeed, fail, get skipped, or get cancelled? | A categorical status per run, not a rolling average. This is what replaced an earlier "Job Success Rate" design: a hard pass/fail/skip/cancel state you can alert on immediately, instead of a 7-day percentage that could quietly tolerate one failure a week. | **Execution status** | 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](/concepts/metrics) used everywhere else in PRIZM, so a dbt job shows up in the same Alerts feed and trust-scoring model as any other asset.