SQL, data modeling, data quality, EDA, visualization · insight-0063
Check source freshness against an explicit SLA, more often than the SLA itself
- Evidence type
- documented fact
- Difficulty
- easy
- Roles
- Data analyst, ML engineer
- Industries
- cross-industry
Summary: situation, action, reason, boundary
Situation
A morning revenue dashboard occasionally shows yesterday's numbers unchanged because an upstream load failed silently.
Action
For each source, record when rows were loaded, define warn and error ages from the business need, run freshness checks at least twice as often as the tightest SLA, and show the data's as-of time on every dashboard.
Reason
Freshness failures produce no error in the consuming query; only an explicit age check turns them into alerts.
Boundary
Dashboards, scheduled reports, feature pipelines and model scoring jobs.
Symptom or risk
Stale data looks like real data; decisions are made on numbers that stopped updating hours or days ago.
Exceptions
Static reference tables updated on a known calendar need a calendar check, not an age threshold.
Trade-offs
Frequent checks cost compute and can page people; tier by importance.
Pitfalls
Measuring freshness by the load job's finish time rather than the newest event or load timestamp in the data.
Lessons and concepts
Claims and their sources
dbt recommends running source freshness jobs at least twice as often as the tightest SLA, for example every 30 minutes for a 1-hour SLA.