Every value in a SCADA system carries a time, but that time can be applied at very different places - at the field device where the value was measured, or at the server where it was received. The timestamp source is which of those clocks stamped the value, and the choice quietly determines whether your history is accurate. This guide explains device versus server timestamping, why it matters for buffered data and event ordering, and the clock-synchronization pitfalls involved.
Timestamp Source in one line: The timestamp source is the point in the data path where a value's time is assigned - either at the field device that measured it (source or device timestamp) or at the collector or server that received it (ingest or server timestamp). Source timestamps reflect when the value was actually true, which is essential for buffered data and event ordering, but they depend on the device's clock being synchronized.
A value can be timestamped at two very different moments. A device or source timestamp is applied at the RTU, PLC, or field instrument at the instant the value was measured, and travels with the value through the whole chain. A server or ingest timestamp is applied when the collector or historian receives the value, marking when it arrived rather than when it was true. In a healthy system with a fast link, these are nearly identical - the value is measured and received within the same moment - so the difference rarely shows.
The difference becomes decisive the instant there is any delay between measurement and receipt. If a value is measured at 10:00 but does not reach the server until 10:05 because of buffering, queuing, or a slow link, the device timestamp says 10:00 - the truth - while the server timestamp says 10:05 - a lie about when the process was in that state. For anything where the timeline matters, the device timestamp is the correct one to trust, and server timestamping silently misplaces delayed data.
This is why the timestamp source is a provenance question, not just a formatting detail. It tells you what a value's time actually means: when it was true, or merely when it showed up. A historian that records the source timestamp preserves the real history; one that stamps everything on ingest fabricates a history built on network timing, which looks fine until the link is anything but instant.
Buffered telemetry is where source timestamping stops being optional. A device that rides out an outage and forwards hours of readings must have stamped each of them at the device when it was measured, or the whole backlog is worthless. Stamped at ingest, every buffered value lands at the reconnect instant, collapsing hours of history into a single false spike. Stamped at the source, each value drops back into its true position and the outage becomes a recoverable gap instead of a fabrication. Store-and-forward and backfill only work because the data is source-timestamped.
Sequence-of-events analysis raises the bar further. When a cascade of alarms trips across a plant, the order and the sub-second spacing between events is exactly what tells you what caused what. Server timestamps cannot capture that, because network and processing delays reorder and smear the events by more than the intervals you are trying to measure. Genuine sequence of events requires source timestamps generated at the device, often with high-resolution clocks, so the true order survives the trip to the historian.
The same logic underlies any comparison across sites. To line up an event at one wellpad against a related event at another, both must be timestamped on synchronized clocks at the source. If one is device-stamped and the other server-stamped, or their clocks disagree, the comparison is meaningless even though every individual number looks reasonable. Consistent source timestamping is what makes a multi-site timeline coherent.
Source timestamping buys accuracy only if the source clock is right, and that is the catch. A device timestamp is only as trustworthy as the field clock that produced it, and field clocks drift, reset after a power cycle, or were never set correctly. A drifting RTU clock stamps its data minutes or hours off, so its values land at the wrong place on the timeline - and because they carry a device timestamp, the historian trusts the wrong time completely. Bad source timestamps can be more dangerous than honest server ones, because they look authoritative.
The defense is disciplined clock synchronization across the field. Devices should synchronize to a common time reference so their clocks agree with the server and with each other, keeping source timestamps consistent. Where a device cannot be trusted to hold accurate time, some systems detect gross skew and either correct it or flag the data, rather than blindly accepting a timestamp that is obviously wrong. And it is common to record both times - the source timestamp for truth and the ingest timestamp for diagnostics - so a clock problem can be spotted by comparing them.
For a cloud SCADA platform, this matters at scale across many remote sites. Merobix preserves the source timestamp so buffered data and events land at their true time, while keeping the ingest time available to detect skew, and it treats a wildly implausible source timestamp as a signal of a clock fault rather than as real history. The result is a timeline that reflects when things actually happened in the field, defended against the field clocks that occasionally lie about it.
A device or source timestamp is applied at the field instrument, RTU, or PLC when the value was measured, so it reflects when the value was actually true. A server or ingest timestamp is applied when the collector or historian receives the value, so it reflects when it arrived. They match when the link is fast, but any delay from buffering or slow communications makes them diverge, and for accurate history the device timestamp is the one to trust.
Because buffered data is delivered long after it was measured. If the readings are stamped at ingest, an entire outage worth of values lands at the reconnect instant as a single false spike. If they are stamped at the source when measured, each value returns to its true position on the timeline and the outage becomes a recoverable gap. Store-and-forward and backfill depend on source timestamps to reconstruct what actually happened.
Its source timestamps are wrong, so its values land at the wrong place on the timeline - and because they carry an authoritative device timestamp, the historian trusts that wrong time completely. This can misorder events and misalign data across sites even when every individual number looks reasonable. The remedy is disciplined clock synchronization to a common reference, plus detecting gross skew and recording the ingest time so clock faults can be spotted.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.