## TL;DR
A freshness threshold is a number somebody chose, and if an agent generated it from a guess, such as assuming hourly data for a daily asset, the alerts are fiction. Derive the threshold from the asset's actual cadence and the business's tolerance: measure the real interval between materializations over recent weeks, set the lag window comfortably above the normal interval plus the run duration, and if the source is calendar shaped, use a cron based policy that knows about weekends instead of a flat lag.

```text
agent misconfigured the dagster freshness threshold, false stale alerts
```

## Use this when
- Stale alerts fire on assets whose latest data is as recent as the source allows.
- Alerts follow a pattern, such as firing every weekend or before a daily run lands.
- The freshness policy in code was generated or copied from another asset.

## Not for this skill when
- The asset really is older than the business tolerance because a run failed. Fix the run; the alert did its job.
- There is no freshness policy and the stale label comes from a different monitoring tool. Fix that tool's threshold there.

## Steps
1. Read the current policy in the asset definition and note the exact threshold: a maximum lag value or a cron window, and who or what set it. Note the number and its origin if recorded. Verify: the current promise is stated precisely
2. Measure the asset's real cadence from materialization history over several weeks: typical interval, worst normal interval, and the run duration. Note the three numbers. Verify: the threshold discussion uses measured cadence, not vibes
3. Compare the threshold with the schedule that feeds the asset, including the upstream source's own publishing cadence, and note any period where the threshold is mathematically impossible to meet, such as a lag window shorter than the source interval. Note the impossible window. Verify: impossible promises are identified explicitly
4. Reset the policy to fit reality and need: lag above the worst normal interval plus run time, or a cron based freshness policy matching the business calendar. Record the reasoning in a comment beside the policy. Note the new values. Verify: the policy is achievable on a normal bad day, not only on a perfect one
5. Watch the policy over at least one full cadence cycle including a weekend if relevant, and confirm no false stale fires while a genuinely delayed test still would. Note the cycle result. Verify: the alert is quiet for healthy data and still meaningful for late data

## Variant phrasings
### dagster freshness policy threshold too tight false alerts daily asset
The cadence mismatch phrasing.
### dagster maximum lag vs cron freshness policy weekends
The policy type choice search.

Compatibility: Dagster 1.x freshness policies on assets, lag based and cron based. The measurement approach uses materialization history available in the Dagster UI and storage.

## Why it happens
Freshness thresholds fail silently in design and loudly in operation. A threshold is a claim about a pipeline's rhythm, and a generated or copied value encodes some other pipeline's rhythm, or none at all. Flat lag windows are especially brittle for calendar shaped data, since a daily weekday pipeline is more than forty eight hours old by Monday morning while being perfectly healthy, so a twenty four hour lag policy manufactures a weekly false alarm that trains everyone to ignore the real one. Matching the policy type to the data's calendar is the actual fix; widening a flat number only moves the false alarm.

## Edge cases / pitfalls
- Do not set the threshold from the best week in the history. Use a bad but normal week, or the first incident will re-open the tuning argument.
- Multi asset chains inherit the slowest upstream cadence. Set freshness on the end asset from the chain's rhythm, not the asset's own run duration.
- A policy change is a code change. Route it through review like any other contract change, with the measurement attached.
- If the business tolerance is genuinely tighter than the source cadence, the answer is a conversation about the source, not a policy that alerts forever.

## Provenance

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