A normal-status display only proves the system is alive if it also states when it last updated

What it is

A data-freshness indication states when the displayed value was last sampled, received, or processed. It supplies concrete evidence that the system is still running, but only if it names which stage of the data path the timestamp actually refers to — a vague "just updated" label hides more than it reveals.

Why it happens

A client that keeps repainting the screen does not prove a sensor produced a new reading, and the time a server received a message is not the time the field actually sampled it. Collapsing sampling time, transport time, and rendering time into one blanket "updated" label buries the very problems — caching, queuing, clock mismatch — that a timestamp is supposed to expose.

The mechanism flips depending on how the source reports: many SCADA and historian systems use report-by-exception, generating and sending a new sample only when the value moves past a configured deadband, which is a common way to save bandwidth and storage. Under that scheme, a long gap since the last update is completely normal and says nothing about a broken link. Freshness there cannot be judged against a single fixed timeout; it has to be derived from that variable's deadband and its maximum plausible rate of change, which together bound the longest silence the process could produce on its own — paired with a separate heartbeat that does not go through the same deadband, so "should have changed but didn't" can be told apart from "genuinely hasn't changed."

Studying it

Inject delay separately at acquisition, transport gateway, processing, and rendering, and check whether the displayed timestamp can actually localize which stage failed, or whether it only shows a generic "not updated." Clock drift and cross-system log alignment belong in the same study: several subsystems keeping their own local clocks, without time synchronization, can turn a raw comparison of absolute timestamps into a negative or otherwise wrong lag.

Where it stops holding

In a distributed system without NTP-style time synchronization between the acquisition end and the display end, comparing absolute timestamps across nodes can produce a wrong staleness verdict or even a negative delay; a relative sequence number or counter is the safer basis for deciding whether a new sample has arrived. Report-by-exception variables cannot reuse the fixed-timeout logic built for continuously sampled ones, for the reason given above. Batch-produced data — an hourly production rollup, for instance — needs "fresh" and "stale" redefined around its own batch cycle; applying a continuous-variable threshold to it is meaningless.

Applying it

Label each critical variable's timestamp with the stage it represents — sampled, received, or processed — instead of a single generic "updated at." For report-by-exception variables, set the freshness threshold from the deadband and the process's maximum rate of change rather than a fixed number, and route a separate heartbeat that bypasses that same deadband. In distributed acquisition chains, prefer relative sequence numbers or the source's own local timestamp over cross-node absolute-clock comparison. As an acceptance test, run a full four-stage delay injection (acquisition, transport, processing, rendering) on every critical variable and confirm each fault is localized correctly rather than reported as a generic "not updated" — and specifically test restarting only the front-end rendering process, with the back-end data source untouched, to check whether the displayed timestamp gets wrongly bumped to the current time, which is the most common way freshness ends up faked.

Related

• Same group: Y1.05.1 Positive indication of normal operation · Y1.05.2 Ambiguity of static displays · Y1.05.3 Normalization during all-normal operation
• Nearby: Y2.08 Alarm-system performance metrics · Y1.01 Three levels of situation awareness
• Search terms: data freshness · timestamp semantics · report by exception