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.

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.