Data quality checks every BI team needs

The most common data incident isn't wrong data — it's old data presented as current. A freshness check is one rule: 'this table should have rows newer than N hours.' It catches broken syncs, expired credentials, and silently failing pipelines before a dashboard full of last Tuesday misleads anyone.

Row counts are a crude instrument that catches sophisticated failures. If orders average 50,000 rows a day and today loaded 3,000, something upstream broke — a truncated export, a half-finished migration, a filter someone added in the source system. Alert on deviation from a rolling baseline, not fixed thresholds, so seasonality doesn't cry wolf.

Not every column needs a null check — key columns do. Order IDs should be unique and never null; customer references should resolve. Declare these as rules on the handful of columns your joins and aggregations depend on, and you've protected every downstream metric at once.

Prices below zero, dates in the future, percentages above 100, foreign keys pointing nowhere — each is a one-line rule. Individually they feel trivial; together they form the immune system that catches fat-fingered source entries and unit mismatches (cents versus dollars remains undefeated) before they average their way into a KPI.

A failing check that only writes a log line changes nothing. Route failures to the dataset's owner, attach sample failing rows so diagnosis starts immediately, and for critical datasets, block publication until the check passes. Quality checks earn their keep the day a bad load doesn't reach the CEO's phone.