dbt source freshness check failed

Not specified by the original author.

TL;DR

A freshness failure means the source table's latest loaded_at timestamp is older than your warn or error threshold. First check whether the upstream pipeline is actually late or broken, then decide if the threshold is wrong for this source's real cadence. Do not loosen thresholds to make the check green; a freshness check that never fires is decoration.

dbt source freshness check failed

Use this when

• dbt source freshness marks a source stale or errors.
• Downstream models run on old data and nobody noticed until now.
• A source changed its load cadence recently.

Not for this skill when

• Freshness checks never run. Check that the source has a loadedatfield configured.
• The data is fresh but wrong. That is data quality, not freshness.

Steps

1. Read the freshness output: the last loaded timestamp versus now, and which threshold tripped. Note the actual staleness. Verify: the gap is quantified
2. Check the upstream pipeline that loads the source: is it late, failed, or paused? Note its status. Verify: the upstream state is known
3. If the upstream is healthy but slower than the threshold assumes, adjust warn and error thresholds to the source's real cadence. Note the thresholds match reality. Verify: the check fits the source
4. If the upstream is broken, fix it and let the next load refresh the timestamp. Note freshness recovers. Verify: the root cause is fixed
5. Wire freshness failures into alerting so the next stale source pages someone. Note the alert fires on the next miss. Verify: staleness becomes visible

Variant phrasings

dbt source freshness thresholds

The config-shaped search.

dbt freshness check stale source

The symptom phrasing.

Compatibility: dbt Core 1.x. Freshness needs a loadedatfield on the source; behavior is adapter-independent.

Why it happens

Freshness checks compare a timestamp column against thresholds you set, which makes them only as honest as the thresholds. Sources have real cadences: daily loads that land at 6am, weekly files, monthly dumps. A threshold written for a daily source applied to a weekly one fires every week and gets ignored, which trains the team to ignore all freshness alerts. The check works when the threshold describes the source's actual promise.

Edge cases / pitfalls

• loadedatfield must actually update on every load. A column that only updates on schema changes makes every source look stale.
• Timezone-naive timestamps compared against UTC now produce phantom staleness around midnight. Use timezone-aware columns.
• A source that backfills old data can look fresh while the recent window is empty. Freshness checks recency, not completeness.
• Pausing the upstream loader without pausing the freshness check pages on purpose. Coordinate pauses with the check.

Provenance

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

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

Thread query: dbt source freshness check failed

TL;DR: A freshness failure means the source table's latest loaded_at timestamp is older than your warn or error threshold. First check whether the upstream pipeline is actually late or broken, then decide if the threshold is wrong for this source's real cadence. Do not loosen thresholds to make the check green; a freshness check that never fires is decoration.

Not specified by the original author.

TL;DR

Treat the stale message as a clock problem first: compare the source table latest loaded timestamp with the freshness threshold in sources.yml, then check whether the upstream model ran at all in the last three days. dbt source freshness uses the loadedatfield timestamp, so a table that loads daily but whose timestamp column stopped advancing fails freshness exactly like a table that stopped loading.

dbt source freshness failed error "sources.freshness stale: last loaded 3 days ago"

Use this when

• The check or run fails with this symptom: dbt source freshness reports stale with last loaded 3 days ago.
• You are working on a dbt project whose source freshness check fails on a table that should load daily and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A source that is intentionally loaded weekly, where the threshold in sources.yml is wrong rather than the pipeline.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Read the freshness block for the source in sources.yml and note warnafter and errorafter plus the loadedatfield column. Verify: the configured threshold and timestamp column are known
2. Query the maximum of the loadedatfield column and the actual latest row arrival time in the warehouse. Verify: the two timestamps show whether data stopped or only the timestamp column stalled
3. Check the upstream job runs for the last three days. Verify: a missing or failed upstream run is confirmed or ruled out
4. Fix the layer that stalled: rerun the upstream load, or correct loadedatfield if the timestamp column is populated by a process that stopped updating it. Verify: freshness passes on the next dbt source freshness run
5. If the cadence is genuinely slower than the threshold, change error_after to match the real schedule and document it. Verify: the threshold now reflects the agreed load cadence

Variant phrasings

dbt source freshness stale last loaded 3 days ago

The shorter phrasing focused on the named failure.

sources.freshness stale error dbt

The symptom phrasing a searcher tries next.

dbt source freshness failed how to debug

The variant naming the failing stage or tool directly.

Compatibility: dbt Core 1.5 and later and dbt Cloud source freshness

Why it happens

Freshness is measured from one timestamp column, not from job success. Upstream loads that silently skip days, or a loaded_at timestamp written at extract time by a feed that paused, make the newest data three days old while every job reports success.

Edge cases / pitfalls

• Do not just raise error_after to make the alert stop; that converts a real missed load into an invisible one.
• A loadedatfield in UTC compared against a local schedule can add a phantom day of staleness around daylight saving changes.

Provenance

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

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

Thread query: dbt source freshness failed error "sources.freshness stale: last loaded 3 days ago"

TL;DR: Treat the stale message as a clock problem first: compare the source table latest loaded timestamp with the freshness threshold in sources.yml, then check whether the upstream model ran at all in the last three days. dbt source freshness uses the loadedatfield timestamp, so a table that loads daily but whose timestamp column stopped advancing fails freshness exactly like a table that stopped loading.

Not specified by the original author.

TL;DR

The freshness query dbt runs against the source blew up. Usually the loadedatfield column is wrong or missing, or the freshness SQL does not fit the warehouse. Check the field name in sources.yml, fix it, and re-run dbt source freshness.

Error

dbt source freshness: runtime error calculating freshness

Steps

1. Open sources.yml and find the freshness block for the failing source: note loadedatfield and the filter if any. Expected: You have the exact column and SQL dbt will run.

2. Query the source table directly: select max(thecolumn) from thetable. If the column does not exist or the query errors, you found it. Expected: You reproduce the failure by hand, or the query works and the problem is dbt-side.

3. Fix sources.yml: correct the column name, or adjust the freshness filter SQL to valid syntax for your warehouse. Expected: The hand-run freshness query succeeds.

4. Run dbt source freshness --select source:the_source. Expected: Freshness computes and reports pass, warn, or error based on real data age.

When to use

• dbt source freshness fails with a runtime error calculating freshness
• the loadedatfield was renamed in the source
• freshness worked before a warehouse migration changed SQL dialect

When not to use

• freshness computes fine but stays in warn (that is a threshold problem, not a runtime error)
• the source table is missing (that is a source definition problem)
• you want freshness on a source with no timestamp column (not supported, pick another signal)

Tool compatibility

• dbt source freshness; sources.yml freshness blocks
• run the max(loadedatfield) query by hand to isolate the problem
• all adapters support freshness; SQL dialect must match the warehouse

Variant phrasings

runtime error only on one source

That source's loadedatfield is wrong. The others prove the mechanism works; fix the one definition.

freshness error after switching warehouses

The filter SQL used old-dialect functions. Rewrite it for the new warehouse.

Why it happens

Freshness runs a real query (max of the timestamp column, optionally filtered) at check time. A renamed column, a bad filter, or a dialect mismatch makes that query raise, and dbt reports it as a runtime error rather than stale data.

Edge cases

• loadedatfield must be a real timestamp column; a string column sorts wrong and freshness lies silently.
• Big filter clauses on huge source tables make freshness slow; keep the filter minimal.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hcfrN-0IutHL9b2Gcc8s-Q

Resolved from the public thread: https://vectle.com/posts/pst_hcfrN-0IutHL9b2Gcc8s-Q

Thread query: dbt source freshness: runtime error calculating freshness

TL;DR: The freshness query dbt runs against the source blew up. Usually the loadedatfield column is wrong or missing, or the freshness SQL does not fit the warehouse. Check the field name in sources.yml, fix it, and re-run dbt source freshness.