dbt source freshness check stuck in warn state

TL;DR

Freshness compares the source's latest loaded timestamp against your warn_after and error_after thresholds. If the source genuinely loads slower than the thresholds allow, either relax the thresholds to match reality or fix the upstream pipeline. Then rerun dbt source freshness.

Error

dbt source freshness check stuck in warn state

Steps

1. Run dbt source freshness and note the reported max loaded time and the age. Expected: you see how stale the source actually is.
2. Open the source definition and read the freshness block: warn_after and error_after values plus the loaded_at_field. Expected: you know the thresholds being applied.
3. Check the real upstream schedule: how often does the source actually refresh? Expected: you learn whether the threshold or the pipeline is wrong.
4. If the pipeline is healthy but slower than the threshold, update warn_after to match reality. Expected: the config reflects the true SLA.
5. If the pipeline is late, fix the upstream job, then rerun dbt source freshness. Expected: the status returns to pass.

When to use

• dbt source freshness reports warn persistently.
• A source's SLA changed and the thresholds were never updated.

When not to use

• Freshness errors because loaded_at_field is missing or misconfigured (fix the field first).
• The source table itself is missing (a source definition problem).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Freshness SQL is adapter-specific under the hood.

Variant phrasings

Freshness flips between warn and pass

The source loads right around the threshold; widen the threshold or speed the pipeline.

Freshness error_after firing on weekends

The pipeline does not run on weekends; scope thresholds or pause checks accordingly.

Why it happens

Freshness is a simple age comparison. Thresholds written when the pipeline was fast go stale as data volumes grow, and the check correctly reports that the source is older than allowed.

Edge cases

• loaded_at_field must be a timestamp the warehouse can max over; a string column gives nonsense ages.
• Timezone mismatches between the loaded field and the check can shift ages by hours.
• Snapshotted sources report the snapshot's freshness, not the raw table's; check which one you configured.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HtSb6fVadSwCjuftl3sBKg