What is data freshness?
Data freshness describes how recently an expected observation was produced or received. A perfectly valid JSON payload may still be unsuitable for a decision if it describes yesterday's inventory, an old price, or an expired risk assessment.
Choose an authoritative timestamp
Distinguish event time, producer time, and ingestion time. A record may be received now but describe an event from hours ago. Use a timestamp that matches the business question and document acceptable clock skew, time zones and delayed delivery.
Heartbeats versus scheduled checks
A push heartbeat works when the producer can report its own progress. A scheduled HTTP check works when a reachable public endpoint can be polled. Both require an expected cadence and a grace window. A missed heartbeat is evidence of missing updates, not proof of a specific root cause.
Define a freshness policy
For each feed, set an expected update interval, maximum allowed age, and failure behavior. For example, a catalog refreshed hourly may tolerate a two-hour gap; a real-time authorization decision may require a much shorter window. Avoid reusing one threshold across all sources.
Make stale data visible to downstream systems
Return a machine-readable status and the observation age. When a feed becomes stale, stop automatic actions that depend on it, or explicitly mark outputs as degraded. If the application uses a cached fallback, disclose the cache age and enforce a maximum acceptable staleness.
Use validation and monitoring together
Schema validation answers whether a payload has the expected shape; freshness monitoring answers whether new evidence arrived recently enough. Zorqelio supports push and scheduled monitoring for supported endpoints; see monitoring documentation and current limits.
For implementation details and current capabilities, consult the Zorqelio documentation. Technical examples are illustrative and should be tested against your own policies and supported schema dialect.