freshness check green while upstream table stopped loading two days ago failure

Not specified by the original author.

TL;DR

Follow the timestamp, not the status light: the freshness check is green because it reads a timestamp that still advances, from a heartbeat, a metadata field, or an empty partition write, while the real table stopped loading two days ago. A green freshness check on a dead table means the check measures the wrong signal. Row arrivals are the ground truth; timestamps are only a proxy that can keep moving on their own.

freshness check green while upstream table stopped loading two days ago failure

Use this when

• The check or run fails with this symptom: a freshness check stays green while the upstream table stopped loading two days ago.
• You are working on a freshness monitor on a table fed by a pipeline that can write metadata or empty batches without new data 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 that legitimately receives no new rows on weekends, where the pattern is the schedule rather than a broken load.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Count rows by arrival date in the table for the last five days. Verify: the day arrivals actually stopped is visible
2. Identify exactly which timestamp or signal the freshness check reads. Verify: the checked signal is named
3. Compare that signal with row arrivals over the same window. Verify: the signal advanced on days with zero arrivals, proving the mismatch
4. Repoint the check at row arrivals or at the load completion record for real batches, and add a minimum row threshold where volume allows. Verify: the check now fails on a simulated stopped load
5. Backfill or rerun the missed loads and confirm arrivals resume. Verify: freshness returns to green on real data

Variant phrasings

freshness check green upstream table stopped loading

The shorter phrasing focused on the named failure.

freshness check passes but no new data failure

The symptom phrasing a searcher tries next.

freshness check wrong timestamp signal fix

The variant naming the failing stage or tool directly.

Compatibility: dbt source freshness, Soda freshness checks, and Monte Carlo freshness rules

Why it happens

Pipelines can keep touching a table without delivering data, through empty extracts, metadata-only writes, or a loaded_at default that stamps the job time rather than the data time. A freshness check tied to those signals reports health while the business data ages.

Edge cases / pitfalls

• A check that passes during an outage loses trust permanently; after fixing the signal, replay the outage window to show the check would have fired.
• Heartbeat tables exist to prove a pipeline is alive; keep them separate from the data tables they accompany so the signals never mix.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstXXIXy5mqwgYbb-MY1aQmg

Resolved from the public thread: https://vectle.com/posts/pstXXIXy5mqwgYbb-MY1aQmg

Thread query: freshness check green while upstream table stopped loading two days ago failure

TL;DR: Follow the timestamp, not the status light: the freshness check is green because it reads a timestamp that still advances, from a heartbeat, a metadata field, or an empty partition write, while the real table stopped loading two days ago. A green freshness check on a dead table means the check measures the wrong signal. Row arrivals are the ground truth; timestamps are only a proxy that can keep moving on their own.

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

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