Last checked is not the same as last changed

A page says “updated five minutes ago.” Did the product change, did the collector run, or did the database rewrite the row?

Those events deserve different timestamps. Combining them makes freshness difficult to interpret.

Keep observation and event time apart

Store when the source was fetched, the period its data describes and any event date supplied by the source. A current fetch can return old information. A newly discovered record can describe an older event.

For a hypothetical price tracker, a price first seen today may have changed yesterday or earlier if collection was interrupted. “First observed” is more accurate than claiming the exact moment of change.

Define a useful freshness threshold

Different signals need different cadences. A slowly changing publisher description and a daily chart do not necessarily need the same refresh schedule. Choose thresholds based on the decision the user makes and the cost of collecting the data.

When a source exceeds its threshold, show the stale state. Do not replace the last good observation with a fabricated current value or silently hide the failure behind a fresh page timestamp.

Preserve partial success

A refresh can update metadata while reviews fail. Record freshness per evidence type so success in one area does not imply success everywhere.

Operational logs should identify the failing source and retry status. Customer pages should explain the practical consequence in plain language, without exposing internal credentials or stack traces.

For a research tool, this is part of the evidence contract. Users need to know whether a missing change means nothing changed or the collector has not looked recently.

A timestamp is useful when its meaning is stable. Give each one a precise job, then let the interface explain that job instead of using “updated” as a universal reassurance.