dbt build is green while source data is stale: put freshness before the model

The dbt job passes and the executive dashboard still shows yesterday's figures. In a data-engineering discussion about dbt ownership, practitioners distinguish transformation from ingestion and describe dependency-refresh confusion. A successful SQL transformation proves it ran on available rows. It does not prove the expected feed arrived first.

Map the handoff explicitly

For each critical source, write down the producer, landing table, expected arrival window, timestamp field and downstream build. Where multiple systems load the same table, define which completed load makes the data usable. Do not use a model's latest run time as the source's freshness clock.

Choose the correct dbt gate

dbt's source freshness guide says dbt build alone does not perform source freshness checks. In dbt platform jobs, enabling the Run source freshness checkbox reports freshness but does not necessarily stop later steps on failure; placing dbt source freshness as a run step can stop subsequent steps. Newer freshness configuration guidance documents dbt freshness for configured sources and models, while the source command remains supported. Verify the installed dbt version and job behavior before changing the gate.

Separate warning from failure

Define warn_after for investigation and error_after for a stale result that should block delivery. Check the source timestamp used by the adapter and handle legitimate no-data days. Route a failure to the ingestion owner with the last observed arrival time, not merely to the dbt model author.

Adovo’s view

A transformation can be correct and the business answer can still be late. Freshness is a contract at the handoff between producer and consumer. Make that contract executable before a green build becomes false reassurance.