freshness check failed error: table not updated in 24 hours stale da

Not specified by the original author.

TL;DR

Prove whether the table is stale or the clock is wrong: check the table's latest load and event timestamps directly, compare them with the freshness window and the timezone the check uses, and inspect the loader's last successful run. A table untouched for 24 hours with a healthy loader usually means the check reads the wrong timestamp column.

freshness check failed error: table not updated in 24 hours stale data failure

Use this when

• The check or run fails with this symptom: the freshness check reports the table as not updated within 24 hours.
• You are working on a freshness check failing on a table that should update 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 volume anomaly with fresh timestamps, which points at counts rather than timing instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Query the maximum event timestamp and the maximum load timestamp on the table and record both. Verify: both timestamps are known and compared
2. Review the loader or orchestration history for the last successful run and any skipped or failed runs in the window. Verify: the loader's recent run history is established
3. Inspect the freshness check configuration for the timestamp column, the threshold, and the timezone it assumes. Verify: the check's column, threshold, and timezone are explicit
4. Fix the failing side: rerun or backfill the loader if data is missing, or correct the check's column or timezone if data is current. Verify: the correction matches the confirmed cause
5. Rerun the freshness check after the next load cycle and confirm it passes on fresh data. Verify: the check passes on the following cycle

Variant phrasings

freshness check failed table not updated 24 hours

The verbatim stale phrasing.

freshness check failed but table updated timezone

The false-alarm phrasing for timezone and column mistakes.

dbt source freshness error stale data

The dbt source-freshness phrasing.

Compatibility: Soda, dbt source freshness, Monte Carlo style monitors, and custom freshness checks

Why it happens

Freshness checks compare a stored timestamp with a window, so loader outages, timezone mismatches between the check and the warehouse, and checks pointed at event time while loads batch overnight all produce the same stale verdict on very different underlying states.

Edge cases / pitfalls

• Separate event freshness from load freshness in the check names. Teams debug the wrong one constantly.
• Holiday and weekend cadences need calendar-aware thresholds or the check cries wolf weekly.

Provenance

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

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

Thread query: freshness check failed error: table not updated in 24 hours stale data failure

TL;DR: Prove whether the table is stale or the clock is wrong: check the table's latest load and event timestamps directly, compare them with the freshness window and the timezone the check uses, and inspect the loader's last successful run. A table untouched for 24 hours with a healthy loader usually means the check reads the wrong timestamp column.

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

Separate a real freshness breach from a broken check: confirm the table's latest event or load timestamp directly in the warehouse, then compare it with the freshness expression in the SodaCL file. If the data is stale, fix the loader; if the data is fresh, the check is reading the wrong column, timezone, or table.

soda scan failed: failed checks found error on freshness check

Use this when

• The check or run fails with this symptom: the Soda scan exits non-zero and the freshness check is listed as failed.
• You are working on a Soda scan whose freshness check reports failed checks found 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 scan that cannot connect at all, which is a datasource configuration problem instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Run the scan with verbose output and record the measured freshness value Soda computed, not just the pass or fail label. Verify: you have the measured age Soda used for the decision
2. Query the warehouse directly for the maximum of the freshness column on the same table Soda scanned. Verify: the warehouse maximum timestamp is known for comparison
3. Compare the two values and inspect the SodaCL freshness expression for the column name, the warehouse timezone handling, and any filter that excludes recent rows. Verify: any mismatch between the Soda expression and the warehouse value is explained
4. Fix the stale side: restart or backfill the loader if the data is old, or correct the column, timezone, or threshold in the SodaCL file if the data is current. Verify: the corrected check measures the real table state
5. Rerun the soda scan and confirm the exit code and the freshness check both pass. Verify: the scan exits zero with the freshness check green

Variant phrasings

soda scan failed checks found freshness

The exit-code phrasing from CI logs.

soda freshness check failed but data is fresh

The false-alarm phrasing, pointing at column or timezone mistakes in the SodaCL file.

soda scan freshness threshold configuration

The configuration phrasing for tuning the threshold and column.

Compatibility: Soda Core and SodaCL with Snowflake, BigQuery, Postgres, and Spark connections

Why it happens

Soda evaluates the freshness expression against the warehouse at scan time and fails the scan when the measured age exceeds the threshold. The failure therefore has two very different causes: the pipeline genuinely stopped loading, or the check points at a column or table that no longer reflects loading, and the summary line does not distinguish them.

Edge cases / pitfalls

• Freshness on a load timestamp measures the loader, not the event time. Pick the column that matches the SLA being promised.
• Weekend and holiday gaps trip fixed thresholds. Use a threshold that reflects the real load cadence.

Provenance

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

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

Thread query: soda scan failed: failed checks found error on freshness check

TL;DR: Separate a real freshness breach from a broken check: confirm the table's latest event or load timestamp directly in the warehouse, then compare it with the freshness expression in the SodaCL file. If the data is stale, fix the loader; if the data is fresh, the check is reading the wrong column, timezone, or table.