7 Data Quality Metrics Every Data Engineer Should Track Weekly

Every data team eventually wants a dashboard for itself. Most build the wrong one. They track pipeline run counts and warehouse credit spend, both of which are lagging indicators of nothing that matters.

These are the seven metrics that actually predict whether your CEO will find the next incident before you do.

What does freshness SLA compliance actually tell you?

Freshness SLA compliance measures the percentage of table loads that arrived within their expected window. Compute it per tier, not per table.

• P0 target: 99% of loads within p95 interval or 20% of it, whichever is larger.
• P1 target: 95%.
• P2 target: 90%.

Publish the number weekly. When it drops, do not average across tiers; the P0 line is what matters. A 96% P0 line means roughly 4 out of every 100 P0 loads were late, and one of those probably fed a Monday exec report.

The failure mode this metric exposes is ingestion instability. Freshness misses cluster on specific source connectors, so a dropping SLA usually points at a single Fivetran or Airbyte connector due for attention.

What is mean time to detect and how do you shorten it?

MTTD is the wall-clock time between an incident starting and the first alert firing on it.

• Target: under 30 minutes for P0. Under 4 hours for P1.
• Instrument: subtract incident open time from the last-known-good timestamp on the affected table.

If MTTD is above 60 minutes on P0, one of three things is wrong. Your monitoring cadence is too slow (a task running every 3 hours cannot detect a 45-minute incident). Your baselines are too loose (the anomaly did not exceed threshold). Or coverage is missing (the affected table was not being monitored at all).

Teams that publish MTTD weekly cut it by 30 to 50% within two quarters just from the pressure of being watched.

Why does incident precision matter more than volume?

Precision is real alerts divided by total alerts. Below 80%, the on-call starts filtering the channel, and real incidents get lost.

• Target: 90%+.
• Instrument: at incident close, mark it as real or false_positive. Compute rolling weekly.

Low precision is almost never a monitoring-tool problem. It is a threshold-tuning problem. The fix is not muting the noisy check; it is understanding why the baseline moved. A common cause is seasonality the baseline did not learn: month-end batches, marketing campaigns, product launches. A once-a-year backfill will alert as an anomaly if the baseline window is 30 days.

The team's on-call morale correlates with this metric more directly than any other.

What does coverage percentage measure?

Coverage is the number of monitored tables divided by the number of tables that meet the "governed" bar (P0, P1, or P2 tier).

• Target: 100% of P0 and P1. 70%+ of P2.
• Instrument: join information_schema.tables against your monitoring config table.

The failure mode this exposes is drift. New tables get created every week; if your monitoring inventory does not automatically pick them up, coverage decays quietly. A pipeline that spins up a new schema this quarter for a new product line will not be monitored until somebody notices, which is often after the first incident.

Automate the inventory refresh. Do not rely on humans to remember to add tables.

How do you measure schema change velocity?

Schema change velocity is the number of information_schema deltas per week per critical table. Not to alert on every one, but to spot the tables under active refactor.

• Target: fewer than 3 changes per month on P0 tables.
• Instrument: snapshot information_schema.columns daily, diff against the previous day.

High schema velocity on a P0 table is a leading indicator of an incident inside two to four weeks. Producers who are changing a table's shape rapidly are, in aggregate, more likely to break a downstream model. This is the metric that lets you have the conversation with the producing team before the incident, not after.

The output is a weekly "top 10 most-changed P0 tables" list. If any table on it feeds a customer-facing report, it needs either a contract or a review with the producer.

What is the downstream blast radius per incident?

Blast radius is the number of dbt models plus BI dashboards affected by a single incident, summed across all incidents in the week.

• Target: median blast radius per P0 incident under 15 downstream assets.
• Instrument: query lineage from dbt manifest.json and BI query logs.

A rising median tells you the source layer is doing too much work. When one broken table takes down 40 dashboards, the pipeline is fragile. The fix is not more monitoring; it is intermediate materialization that decouples raw source volatility from consumer contracts.

Blast radius is also the number to show finance. Fifteen affected dashboards translate to a rough dollar figure of decisions delayed or made on wrong data, which is what unlocks the observability budget.

Why should you track mean time to resolve separately from detect?

MTTR is the time between the first alert and the resolved state.

• Target: P0 under 2 hours. P1 under 8 hours. P2 under 24 hours.
• Instrument: close time minus open time on the incident record.

MTTR isolates the fix workflow from the detection workflow. A team can have great MTTD (fast alerts) and terrible MTTR (slow fixes), which usually means ownership is unclear or runbooks do not exist. Publish MTTR by table owner and the source of the delay becomes obvious.

The most common MTTR blocker is not engineering skill; it is the delay between the alert firing and the responsible engineer being awake or in a meeting. A rotating on-call plus a documented escalation policy shortens MTTR faster than any tooling investment.

How do you use all seven together?

Build a single weekly view that answers three questions:

• Is coverage complete? Coverage % and schema change velocity.
• Are we catching things? MTTD, freshness SLA, precision.
• Are we fixing them cleanly? MTTR and blast radius.

Roll them into a composite reliability score if you want a single number to show leadership. The composite matters less than the fact that seven distinct signals move in your dashboard every week, so the failure mode has a place to surface before it becomes an incident.

The mistake to avoid

Most data teams either track nothing or track pipeline vanity metrics like "dbt runs per day." Neither predicts an incident. Track the seven metrics above, publish them weekly, and treat any red trendline as a P1 investigation the same way you would a broken pipeline. The team that instruments itself catches breakage on the metric before it becomes an incident. The team that does not, keeps finding out from a stakeholder.