Data Quality Monitoring with Routed Ownership

The problem

A dashboard is wrong.

Someone notices on Thursday, mentions it on Friday, and by the time anyone investigates the cause is four days upstream: a source system stopped delivering on Monday night, and every pipeline downstream continued to run successfully against unchanged data.

Nothing failed. The jobs were green.

The data was stale, and staleness has no exception to throw.

Most organisations respond by adding tests.

The tests are reasonable and the failures are real, and within a few months the alert channel receives enough noise that people mute it.

A muted channel is worse than no monitoring, because the team believes coverage exists.

The failure that eventually matters arrives in the same channel as the eleven known-broken tests nobody has had time to fix.

The two problems are distinct and both have to be solved.

The first is detection: knowing that something is wrong, including the silent failures where a pipeline succeeds against bad input.

The second is routing: getting each signal to the one person who can act on it, with enough context to act.

Detection without routing produces an ignored channel. Routing without ownership produces an alert that lands in a shared inbox and dies there.

When to use this

• Pipelines feed reporting or decisions that people act on.
• There is more than one source system, particularly where some sources are owned by teams outside the data function.
• There is any history of stakeholders discovering data problems before the data team does.
• Regulatory or financial reporting depends on the output.
• The team is large enough that “everyone sees everything” no longer works, which happens earlier than expected.

When not to use this

Nobody will own the alerts

This is the disqualifier that matters and the reason most implementations decay.

A monitoring system whose output has no named recipient with an expectation to respond is a system that generates noise and a false sense of coverage.

Assign ownership first, even if that means monitoring fewer tables.

One person runs everything and sees every failure

Routing is unnecessary overhead at that scale.

Freshness and volume checks are still worth having; the ownership-routing layer is not yet.

The pipeline is not yet stable

Monitoring a platform under active initial construction produces constant failures that reflect development rather than data problems.

The team learns to ignore alerts during exactly the period when the habit forms.

Stabilise first, then monitor.

The real problem is an absent upstream change process

Where source teams change schemas without notice, monitoring will detect every break faithfully and fix none of them.

It converts silent failures into loud ones, which is a genuine improvement, but the actual fix is a contract with the upstream team.

Monitoring becomes the evidence you use to ask for one.

Architecture

Checks sit at the boundary where a problem originates rather than where it eventually surfaces.

Freshness and schema checks run against sources before anything is built on them, so a stale or structurally changed source can be detected before bad data quietly propagates downstream.

Volume and null-rate assertions run at ingestion.

Structural tests — uniqueness, referential integrity and accepted values — run during transformation.

Business-level assertions and reconciliation run at the marts, where the numbers people actually quote live.

Every check carries ownership metadata

Every check carries three pieces of metadata alongside its logic:

• An owner.
• A severity.
• A note explaining what the check assumes and what to do when it fires.

This is what separates a working monitoring system from a noisy one.

The owner is the team accountable for the data, not necessarily the team that built the pipeline.

A freshness failure on a source system needs to reach the people who operate that source.

Severity distinguishes a warning that reports from an error that blocks downstream models from building on data already known to be bad.

The response note is what makes a 3am alert actionable by someone who did not write the check.

Routing follows the metadata

Warnings go to the owner’s channel.

Errors block downstream work and page whoever is on call.

Repeated failures on the same check open a ticket.

A check that has fired for three weeks is no longer an alert. It is an accepted defect.

That defect should be visible in a backlog rather than recurring indefinitely in an operational channel.

Components

Tradeoffs

Implementation notes

Start with freshness on every source

Start with freshness checks on every source and almost nothing else.

Stale data is one of the most common causes of a wrong dashboard and one of the easiest failures to detect.

Freshness checks also have a high signal-to-noise ratio, because a source that has stopped delivering is unambiguously a problem.

Add depth after this layer is trusted.

Use graduated thresholds

A warning state before an error state gives the owner time to investigate before anything blocks.

It converts a binary pass/fail system into a signal people can act on proactively.

A monitoring system with only hard failures trains the team to treat every alert as an emergency, and eventually to stop treating any alert as one.

Store ownership with the check

Write the owner and response note into the check definition itself, in the same file as the source or model.

Documentation that lives elsewhere goes stale within a quarter.

A check whose owner has left the organisation is a check that will eventually fire into a void.

Review muted, failing and disabled checks monthly

Treat this list as a debt register.

Every muted check is a coverage gap the team may have forgotten exists.

A recurring review is the mechanism that surfaces those gaps before an incident does.

Track time-to-resolution per source

Failure counts alone do not show where the operating model is weak.

Repeated failures against the same source with slow resolution are evidence that the relationship with that upstream system needs attention.

That measurement becomes a concrete argument for a data contract rather than a general complaint.

Monitor the monitoring system

Alert on the absence of test results as well as on failed tests.

A test suite that silently stopped running reports no failures.

On a dashboard, that can look identical to a perfectly healthy system.

A heartbeat check on the monitoring infrastructure is the least glamorous component in this pattern and one of the most important.

Separate operational and stakeholder communication

Engineers need detailed warnings and technical context.

Business users need to know when a number they rely on is affected, in language that does not reference model names or pipeline internals.

Sending both audiences the same messages guarantees that at least one group eventually stops reading them.

References

• Building a data quality framework with dbt — covers source freshness, schema drift and placement of data-quality tests across pipeline layers.
  dbt
• dbt source freshness best practices — covers warning versus error thresholds, routing freshness alerts to source owners and tracking resolution time.
  Paradime
• Implementing dbt data quality checks with dbt-expectations — extends beyond built-in tests and discusses documenting assumptions, owners, impacts and investigation steps.
  Datadog
• The complete guide to building reliable data with dbt tests — practical guidance on team-based alert routing and enforcing ownership on new models.
  SYNQ
• Elementary data contract tests — compares contract enforcement approaches and how failures map into alert categories.
  Elementary
• How to use dbt-expectations to detect data quality issues — worked examples covering type, freshness and distribution assertions.
  Datafold