data freshness test failed error: latest timestamp is 3 days old failure

Not specified by the original author.

TL;DR

Three days old means either three missed loads or a check reading an abandoned column: list the table's load history for the three days, check the orchestrator for paused or failing jobs, and verify the timestamp column is still the one being updated. Restore the loads in order so downstream tables do not build on a gap.

data freshness test failed error: latest timestamp is 3 days old failure

Use this when

• The check or run fails with this symptom: the freshness test reports the newest data as three days old.
• You are working on a table whose latest timestamp is three days old 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 table designed to update weekly, where three days is normal and the threshold is wrong 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 table for its maximum timestamp and count rows per day for the last seven days. Verify: the gap days are identified precisely
2. Check the orchestrator's runs for those days: failed, skipped, or paused jobs that feed the table. Verify: the job state for each gap day is known
3. Confirm the timestamp column is still populated by current loads by inspecting the newest loaded rows directly. Verify: the column's currency is verified on raw rows
4. Backfill the gap days in chronological order and watch for source data that itself is missing for those days. Verify: the gap is filled or the source gap is proven
5. Rerun the freshness test and confirm the newest timestamp is within the expected window. Verify: the test passes with a current timestamp

Variant phrasings

data freshness latest timestamp 3 days old

The verbatim three-day phrasing.

freshness test failed pipeline stopped days ago

The stopped-pipeline phrasing for paused or failed jobs.

freshness check reading old timestamp column

The wrong-column phrasing for deprecated timestamps.

Compatibility: Freshness checks in Soda, dbt, and custom monitors on warehouse tables

Why it happens

Freshness ages linearly, so a three-day value usually means the pipeline stopped three days ago: a paused schedule, a failing job nobody routed, or a credential or source that expired. The less common cause is a check still reading a deprecated timestamp column that loads no longer update.

Edge cases / pitfalls

• Route freshness failures to the pipeline owner with the job link, not a generic channel. Ownership halves resolution time.
• A source that stops sending data looks identical to a broken loader. Check the source's own counts.

Provenance

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

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

Thread query: data freshness test failed error: latest timestamp is 3 days old failure

TL;DR: Three days old means either three missed loads or a check reading an abandoned column: list the table's load history for the three days, check the orchestrator for paused or failing jobs, and verify the timestamp column is still the one being updated. Restore the loads in order so downstream tables do not build on a gap.

Not specified by the original author.

TL;DR

Trust the max event timestamp in the source, not the dashboard job status: find why the last successful run loaded a day-old partition, usually a schedule that fired before the upstream partition landed, and rerun the load for the missing day, because freshness here is data age, not job success. Start with the serving values for one entity against the max event timestamp in the offline source, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than retried unchanged.

feature freshness green in dashboard but values are a day old in serving error

Use this when

• You see this exact message or symptom: feature freshness green in dashboard but values are a day old in serving error
• One run, record, call, or object is affected and you can name it
• A retry without changing anything reproduces the same result

Not for this skill when

• The system fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once using the serving values for one entity against the max event timestamp in the offline source, and record the time, the workspace or account, and the one item it names. Verify: you have one failing item identified, not a similar older failure
2. Inspect the dashboard freshness definition, the max event timestamp per feature view in the source, and the upstream partition arrival time versus the load schedule. Verify: you can point to the specific value, field, segment, or state that does not match what this operation needs
3. Apply the fix at that source: Trust the max event timestamp in the source, not the dashboard job status: find why the last successful run loaded a day-old partition, usually a schedule that fired before the upstream partition landed, and rerun the load for the missing day, because freshness here is data age, not job success. Verify: the corrected value or setting is visible in the system itself, not only in a local file or the agent notes
4. Re-run the original operation on the single affected item first. Verify: that one item completes with no trace of the failure described above, and the online and offline values for that entity agree
5. Check the downstream result a user or the next job would see, comparing it against the source for the same item. Verify: the downstream result agrees with the source in content and in timing
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the failure and the fix, and no earlier item regressed

Variant phrasings

feature freshness green in dashboard but values are a day old in serving error

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the item the log or record names.

Tool-first phrasing of this failure

The phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does this keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the input, setting, or record state, not in the attempt.

Compatibility: Any feature store freshness dashboard, scheduled materialization, daily partitioned sources.

Why it happens

Dashboards commonly chart the last job run, and a job can succeed on yesterdays partition when todays has not landed. Serving then returns correct-looking values that are silently a day old.

Provenance

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

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

Thread query: feature freshness green in dashboard but values are a day old in serving error

TL;DR: Trust the max event timestamp in the source, not the dashboard job status: find why the last successful run loaded a day-old partition, usually a schedule that fired before the upstream partition landed, and rerun the load for the missing day, because freshness here is data age, not job success. Start with the serving values for one entity against the max event timestamp in the offline source, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than retried unchan

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.