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.

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