DE//AGENT
Explore
Tutorial Lesson 9 of 10 · The Data Quality Series community beginner

Respond to a failing quality expectation

A quality expectation failed in production and bad data may be reaching consumers. Follow the data-quality-failure runbook: read the failure precisely, quantify it, then make the one decision that matters — block, quarantine, or pass-with-warning.

At a glance

When A quality expectation failed in production; A freshness or volume check alarmed, or consumers report wrong numbers
Where Data Quality
Why The decision on every failure is the same — block, quarantine or warn; getting it wrong ships bad data to consumers or pages people at 3am for nothing.

Learning objectives

  • Read a failing expectation precisely — column, rule, value
  • Quantify a failure — how many rows and which ones
  • Decide block vs quarantine vs pass-with-warning on evidence

What you need

  • The failing test name and its output (dbt or Great Expectations)
  • Read access to the failing table
  • [object Object]

Steps

  1. Read the failing expectation precisely: which column, which rule, what value. (from runbook-data-quality-failure )
  2. Quantify: how many rows, and which ones (sample them). (from runbook-data-quality-failure )
  3. Decide: block, quarantine, or pass-with-warning. (from runbook-data-quality-failure )
  4. Quarantine the failing rows, publish the clean set, keep the bad set for reprocessing. (from runbook-data-quality-failure )
  5. If it is upstream, halt promotion and notify the producer. (from runbook-data-quality-failure )
  6. If it is a false positive, loosen the threshold with evidence. (from runbook-data-quality-failure )

Check yourself

  • `dbt test --select fct_orders` isolates the failing test, and `SELECT * FROM fct_orders WHERE order_id IS NULL LIMIT 20;` samples the offending rows.
  • Given an upstream null-rate jump, you halt promotion and notify the producer instead of loosening the threshold.

Worked example

Isolate the failing test — from runbook-data-quality-failure 

dbt test --select fct_orders  # see the failing test

Sample the offending rows — from runbook-data-quality-failure 

SELECT * FROM fct_orders WHERE order_id IS NULL LIMIT 20;

The three-way decision — from runbook-data-quality-failure 

Quarantine the failing rows, publish the clean set, keep the bad set for reprocessing.
If it is upstream, halt promotion and notify the producer.
If it is a false positive, loosen the threshold with evidence.

Sourced from

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

  • Loosening a threshold to silence an alarm is only right with evidence it was a false positive.
  • Bad data that already reached consumers needs disclosure, not just a fix.
  • Blocking on a warning-tier expectation turns small blips into outages.

Production considerations

  • Tier expectations: critical blocks, warnings alert.
  • Keep a quarantine table so a bad batch never ships.

Diagram

expectation failed
   |
   |- read precisely --> column + rule + value
   |
   |- quantify --> row count + samples
   |
   |- decide --> upstream --> halt promotion --> notify producer
   |             false positive --> evidence --> loosen threshold
   |             genuine --> quarantine rows --> publish clean set

Registry stats

Verification community · Oct 21, 2026
Completeness 81
Trust multiplier ×1.25
Composite 34.15 · adequate
Freshness 3 days since last source check
Difficulty beginner
Version 0.1.0
License CC-BY-4.0
Security flags none