Think Build Implement Repeat
Data & Scraping

Data Quality Checks That Run Without Anyone Remembering

Last updated:

Problems found late are expensive

A data error found the day it happens is a fix. The same error found six weeks later has propagated into reports, decisions and customer communications, and correcting it means unpicking all of them.

The difference is entirely whether anything was checking.

The six checks

  1. Row counts against a rolling expectation. Alert on deviation, not just on zero.
  2. Completeness of fields that matter. A jump in null rate is usually a format change upstream.
  3. Distribution of key values. Prices ten times higher usually means units changed, not the market.
  4. Freshness. When was the newest record created? Stale data that keeps loading is a silent failure.
  5. Referential integrity. Orders without customers, lines without orders.
  6. Duplicate rate, which creeps up quietly and distorts every count.

Alert on deviation, not on thresholds

A fixed threshold is wrong within a quarter as the business grows. Compare against a rolling window — “today is 60% below the last fourteen days” — and the check stays useful without maintenance.

Allow for known patterns: weekends, month end, seasonal peaks. A check that cries wolf every Sunday is one nobody reads by February.

Quarantine rather than fail

One bad record should not stop a load. Route failures to a quarantine table with the error and the original payload, process everything else, and report the quarantine count as its own metric.

Then actually review the quarantine. A growing pile nobody looks at is silent failure wearing a different hat.

Publish the results where people see them

A short daily summary — what ran, what passed, what was quarantined, when data was last refreshed — in the channel the team already uses.

Freshness in particular should be visible on any dashboard. Stale data presented as current is the most damaging reporting failure there is.

Start with three

Do not build all six at once. Row count, freshness and completeness on your two most important tables catches the large majority of problems and takes a day.

Add the rest as specific incidents show you what you are missing, which is a better guide than a checklist.

Frequently asked questions

What does this cost to add?

A few days of work for a handful of pipelines, plus a small ongoing cost. It is among the cheapest insurance available on any data platform.

Who should receive the alerts?

Someone who can act, and someone in the business who cares about the number. Technical-only alerting means data quality is treated as an IT problem rather than a business one.

Do we need a data quality tool?

Not at small scale. Scheduled queries with comparisons and a summary message are adequate for most businesses.

How do we know what normal looks like?

Run the checks in reporting-only mode for a fortnight first. That establishes the baseline and shows you which checks would have been noisy.

Keep reading

Wondering whether your reports are right?

Three checks on your two most important tables is a day's work. Tell us what your data pipeline looks like.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Web ScrapingData Science