Testing, 1, 2, 3: Catching silent data failures beyond dbt tests

Your dbt tests are all green. Your data is wrong anyway.

dbt tests are great at catching failures you already know how to describe: uniqueness issues, unexpected nulls, referential integrity problems, and other explicit assertions. But some of the most painful production failures are the ones no rule anticipated: a row count that quietly halves, data that is stale but still “valid,” or a metric that drifts enough to mislead a dashboard while passing every test.

I’ll share a practical framework for drawing the line between dbt tests and production monitoring: which checks belong in the transformation layer, which signals need observability outside it, and how the two work together. We’ll look at examples such as freshness, row-count anomalies, coverage shifts, and drift detection.

You’ll leave knowing how to decide what to test, what to monitor, and how to catch silent failures without turning every edge case into a brittle pass/fail rule.