When a data quality check fails, should you stop the pipeline, quarantine the data, retry, or publish?

DataKitchen's rule: stop the pipeline when wrong data would be used, can't be pulled back, and users can live with yesterday's numbers. Quarantine when the bad rows are identifiable and the rest of the load is good. Retry only timing failures, on idempotent loads. Publish with a warning when data is visibly incomplete rather than silently wrong.

Key points

  • DataKitchen recommends three questions to decide what a failed data quality check should do: how much damage a wrong number causes, whether it can be pulled back after someone uses it, and how old the data can be before it's useless.
  • A tripwire that stops the pipeline keeps production on the last good data. DataKitchen's Guide to DataOps Tests prefers stopping to alerting because an alert arrives after the bad data has already moved.
  • Quarantine moves failing rows aside and keeps a count that reconciles: in DataKitchen's October 2026 Jaffle Shop migration test, 483 empty orders went to a quarantine table, and 61,948 source orders reconciled to 61,465 migrated plus 483 quarantined.
  • DataKitchen's advice is to retry a failed load only for timing problems, never data problems, and only when the load is idempotent: its August 2026 Seven Deadly Sins post shows a non-idempotent retry turning 1,000 rows into 2,000.
  • DataKitchen's August 2026 efficiency post gives the default: halt when data would be silently wrong, warn when it would be obviously incomplete, because a wrong number gets used and a missing one gets questioned.

Say a check fails at 6:14am and finance opens the dashboard at 8. You have about two hours to pick one of four moves. If you haven’t decided which, the orchestrator’s default decides for you.

Decide in advance instead, per rule, with three questions.

Three questions, four moves

How bad is a wrong number here? Can you pull it back after someone uses it? And how old can the data be before it’s useless? This is how DataKitchen maps the answers to a move.

Business impact if wrongReversible after use?Older data acceptable?Move
High: customers, money, a model, a board deckNoYesStop. Serve the last good data
HighNoNoStop, and tell the people waiting why it’s late
Failure isolated to identifiable rowsYes, rows can be released laterYes, for those rowsQuarantine the rows, publish the rest, reconcile the count
Cause is timing: late file, lock, timeoutn/aYes, for a short waitRetry, if the load is idempotent. Otherwise stop
Low, or the gap is obvious to the readerYesn/aPublish with a warning to the rule’s owner
None. You only want the trendn/an/aPublish, record the number

The default when you’re unsure comes from DataKitchen’s efficiency post: halt when the data would be silently wrong, warn when it would be obviously incomplete. A wrong number gets used. A missing one gets questioned.

Stop

A tripwire does the stopping: a test task that fails, so the next step never runs and production keeps serving the last good data. The dashboard answer covers where to put them. The point is reversibility. The Guide to DataOps Tests prefers stopping to alerting because an alert arrives after the data has moved, and a model trained on a column that lost 30 percent of its values can’t be recalled by a notification.

Stopping costs you freshness, and sometimes an SLA. Chip Bloche, DataKitchen’s VP of Data Engineering and Quality Innovation, wrote about breaking a critical SLA when a stakeholder’s referential integrity test refused to publish a refresh with out-of-sync source data. Late, and the data was right. Leadership was grateful once the team explained what the test had caught.

Quarantine

Quarantine works when the bad rows can be named and the rest of the load is fine. The Write-Audit-Publish pattern does it at the batch level: write to a staging location, audit there, and publish only what passes. At the row level, the migration test moved 483 empty orders ($0 subtotal, no line items) to a quarantine table and kept the books balanced: 61,948 source orders equal 61,465 migrated plus 483 quarantined.

The count is what makes it quarantine. Microsoft Fabric’s ON MISMATCH DROP, as DataKitchen’s Microsoft post describes it, deletes the failing rows and writes a number to a log. The gold table looks clean because the evidence left. If nobody reconciles the quarantined count, your totals are silently short, which is the failure you were trying to stop.

Retry

Our rule: retry for timing problems only. A file that hadn’t landed, a lock, a timeout. Bad source values come back identical on the second run.

And retry only an idempotent load. The Seven Deadly Sins post calls out the retry that loads twice: a non-idempotent load turns 1,000 rows into 2,000, and an agent that sees a non-zero exit reruns the command. A FITT pipeline makes rerunning safe by design.

Publish with a warning

The Guide puts most rules that matter here, as soft fails. Its three tiers: hard fails stop the pipeline and should be very few, soft fails let data through and warn the owner, and informational checks record a number for the trend. The starter checks answer assigns a tier to each common check. If a rule warns every night with nothing wrong, it needs fixing, and the false-positive answer covers how to demote it and when to promote one to blocking.

A fifth move exists: fix the data and rerun. Keep a person in it. DataKitchen’s human-gated agent pattern has the agent propose SQL in a ticket, wait for approval, and apply fixes in one transaction to a copy table, so by default the original never changes.

Frequently asked questions

Short answers to the follow-up questions people ask next.

When should a failed data quality check stop the pipeline?

When the data would be silently wrong, someone would act on it, and the damage can't be undone by a correction afterward. A model trained on a column that lost 30 percent of its values, or a customer report already sent, can't be recalled. DataKitchen's Guide to DataOps Tests explains the mechanism: a tripwire stops the next step, so production keeps serving the last good data.

What does it mean to quarantine bad data?

Quarantining moves the rows that failed a check into a separate table and publishes the rest, while keeping a count that reconciles. In DataKitchen's October 2026 Jaffle Shop migration test, 483 empty orders went to a quarantine table and 61,948 source orders reconciled to 61,465 migrated plus 483 quarantined. Deleting failed rows and logging a number isn't quarantine, because the evidence is gone.

Is it safe to retry a pipeline after a data quality failure?

DataKitchen's advice is to retry only when the cause was timing, such as a file that hadn't landed yet, and only when the load is idempotent. A retry doesn't change bad source data, so it fails again or, worse, passes on a partial load. DataKitchen's Seven Deadly Sins post notes that an agent retrying a non-idempotent load turns 1,000 rows into 2,000.

Is it ever right to publish data that failed a check?

Yes, for soft and informational failures. DataKitchen's Guide to DataOps Tests describes three tiers: a hard fail stops the pipeline, a soft fail lets data through and warns the rule's owner, and an informational check records a number silently. Publish with a warning when the data is visibly incomplete, because users question a missing number but use a wrong one.

Is a late dashboard better than a wrong one?

Usually, when the wrong number would drive a decision. In DataKitchen's How I Broke Our SLA post, a stakeholder-written integrity test stopped a warehouse refresh, the SLA was missed, and leadership was grateful once the team explained what the test had caught. Tell people the data is late and why. Silence turns a stopped pipeline into a mystery.

Try it on your own data

DataOps TestGen is free and open source. Profile a table and generate its tests this afternoon.