dagster freshness policy violation, asset marked stale

TL;DR

A freshness policy is a promise: this asset will be materialized within a stated window of its upstream data or on a stated cadence. Dagster marks the asset stale when the latest materialization is older than that promise allows, which usually means an upstream asset stopped landing, a schedule or sensor did not fire, or the policy window is tighter than the pipeline can physically run. Compare the policy deadline with the actual upstream and asset timestamps before loosening anything.

dagster freshness policy violation, asset marked stale

Use this when

• Dagster shows a freshness policy violation or stale badge on an asset.
• Freshness alerts fire on a rhythm, such as every Monday or after holidays.
• Upstream assets look recent but the governed asset is flagged stale.

Not for this skill when

• The asset run is actively failing on code errors. Freshness is a symptom there, not the diagnosis.
• There is no freshness policy on the asset. A plain old asset is just unscheduled, not stale.

Steps

1. Read the asset freshness policy in code: the maximum lag or the cron based window it declares. Note the exact deadline rule. Verify: the promise being measured is known word for word
2. In the asset view, compare the latest materialization time of this asset and of each upstream asset against that deadline. Note which link in the chain is actually old. Verify: the stale link is located, upstream or here
3. Check the automation that should have run it: schedule, sensor, or automation condition evaluations around the missed window, including whether the daemon was up. Note any skipped or errored evaluation. Verify: the missed trigger is explained
4. Look for calendar traps: a cron window written in a different timezone than the team assumes, or a weekday only cadence measured against a policy that counts weekends. Note any mismatch. Verify: timezone and calendar effects are confirmed or cleared
5. Fix the real link: restore the upstream run or automation, or, if the policy itself promises more than the business needs, change the policy in code with the reason recorded. Then watch one full cycle. Note the asset returns inside its window. Verify: freshness holds for a full cycle, not just one manual run

Variant phrasings

dagster asset stale freshness policy maximum lag

The lag based policy phrasing.

dagster freshness check failed cron window

The cron based policy version.

Compatibility: Dagster 1.x freshness policies, both lag based and cron based, evaluated by the Dagster daemon. Exact policy classes differ across 1.x releases; the timestamp comparison is the constant.

Why it happens

Freshness is computed from timestamps, not from intentions. Dagster takes the newest materialization, applies the policy arithmetic, and reports a violation the moment the deadline passes, whether the cause is a broken upstream, a paused schedule, or a policy written during a hack week that promised hourly data from a daily source. Recurring violations on a calendar pattern are the tell for a policy and cadence mismatch rather than a broken pipeline, because broken pipelines do not respect weekends.

Edge cases / pitfalls

• Manually materializing once clears the badge and proves nothing. Judge the fix over the next scheduled cycle.
• A partitioned asset can be fresh on recent partitions and stale on the partition the policy evaluates. Check which partitions the policy covers.
• Backfills rewrite old partitions without making the asset fresh. Freshness follows the relevant latest data, not run activity.
• Alert routing matters: a stale asset nobody owns generates noise until people mute it. Assign the policy an owner when you write it.

Provenance

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