AccelerUpDocs
Data warehouse/Data quality

Data quality

Freshness, nulls, uniqueness and row-count drift — checks on the data itself.

Data Warehouse → Data Quality runs structured checks on tables, rather than alerting on a query you wrote.

Check kinds

CheckAsks
FreshnessWhen did this table last receive a row?
Null rateWhat share of this column is null?
UniquenessAre these values unique?
Row countIs the count within the expected range?
Row-count driftHas the count changed unusually against its own history?

Freshness is the one to start with

A stale table makes every other check and every dashboard reading it wrong — and wrong in the most dangerous way, because the numbers look plausible.

Important

A freshness check is worth more than the sum of every other check on that table. "Failures dropped to zero" and "the pipeline stopped four hours ago" produce the same reading, and only one of them is good news.

Use the same value as a guard on SQL alerts reading the same table, so a stale mirror reports staleness rather than a metric.

Configuring

FieldNotes
Table and column
Check kind
Threshold
Schedule
Severity

Results

Each run records pass/fail with the measured value. History shows drift over time — a null rate creeping from 0.1% to 3% is a real problem long before it crosses any threshold somebody picked.

Quality checks or SQL alerts?

Quality checkSQL alert
SetupPick a table and a kindWrite SQL
FlexibilityFixed kindsAnything
Best forStandard checks across many tablesA specific business question

Use quality checks for the checks every table should have, and SQL alerts for the ones only you would think of.

  • Lineage — what else is affected when a table goes stale

Where this behaviour lives: backend/internal/service/dwh_advanced_svc.go, frontend/src/app/dwh/quality/. If the code and this page disagree, the code is right — please fix the page.

Part of Data warehouseQuerying the warehouse, and alerting on what the query returns.