Historians are built on an unspoken assumption: data arrives in time order, each new value later than the last. Out-of-order data breaks that assumption, arriving with a timestamp earlier than data already stored. It comes from buffered telemetry, retries, and skewed clocks, and it is a genuine data-integrity failure mode that a historian must handle deliberately. This guide explains what goes wrong when time runs backward and how historians reorder, recompress, or reject the late arrivals.
Out-of-Order Data in one line: Out-of-order data is a value that reaches the historian with a timestamp earlier than data already stored for the same tag, rather than after it. It arises from buffered or retried telemetry, network delays, and clock skew, and it forces the historian to insert into the past - reordering, revalidating, and possibly recompressing the affected span, or rejecting the point if it cannot.
Time-series storage is optimized for append. The current archive partition expects each new point to be later than the last, so it can write to the end, extend its index, and let compression compare the point to its immediate predecessor. Every part of that fast path assumes monotonic time. An out-of-order point violates it: its timestamp falls behind the archive's frontier, so it cannot simply be appended - it has to be spliced into a position that is already occupied by later data.
The immediate breakage is in anything that consumed the stream in arrival order. Compression already decided which points to keep based on the neighbors it had seen; a late point inserted between them can change what should have been retained, leaving the compressed span inconsistent. Calculated tags, totalizers, and rolling aggregates that already ran across that time produced results without the late value, so they are now wrong. Even a live trend a user is watching may need to redraw a segment it thought was finished.
The subtle danger is a historian that accepts the point but stores it in arrival order rather than timestamp order. Then a query that walks the archive sees time jump backward mid-stream, and any client or calculation that assumes ordering produces garbage. Handling out-of-order data correctly is not just about accepting it - it is about ensuring the stored result is still ordered by time so everything downstream can keep trusting the timeline.
The most common and legitimate source is buffering. A field device rides out a comms outage by storing timestamped readings, then delivers the whole backlog when the link returns - and that backlog is, by definition, older than whatever was collected live in the meantime. This is the same data that backfill inserts; out-of-order arrival is the timing pattern, and backfill is the archive operation that handles it. When the buffered values carry correct source timestamps, this out-of-order arrival is entirely benign if the historian is built for it.
Retries and multi-path delivery produce it too. A message that failed and is resent, or a redundant collector that delivers a value the primary already sent moments later, can land after newer data. Here the historian often needs to deduplicate as well as reorder, recognizing that the late point may be a repeat of one already stored rather than genuinely new information.
The troublesome source is clock skew. If a field device's clock drifts or was never synchronized, it stamps its readings with a time that disagrees with the rest of the system, so its data can arrive looking out of order - or, worse, looking in order but landing at the wrong place on the true timeline. Unlike buffered data, skew is a defect: the fix is disciplined clock synchronization at the source, because no amount of reordering can correct a timestamp that was wrong when it was written.
Remote oil and gas telemetry generates out-of-order data as a matter of routine. Every wellpad that buffers through a dropped cellular link, every redundant path, every site whose clock drifts contributes late arrivals. A cloud SCADA historian that assumed strict order would either reject this data or corrupt its own timeline, so tolerating and correctly reordering out-of-order arrivals is a baseline requirement for monitoring sites on unreliable links rather than an edge case.
The right behavior blends acceptance with limits. Genuine buffered data with correct timestamps should be accepted and reordered into place, with any affected compression and derived values revalidated so the record stays consistent. But a point whose timestamp is implausibly old - far outside any reasonable buffer or into a sealed retention period - is better flagged or rejected than trusted, because it more likely reflects a clock fault than real history. Distinguishing legitimate lateness from a bad timestamp is the heart of good out-of-order handling.
Merobix is designed around out-of-order arrival as normal for field telemetry. Buffered data from a reconnecting gateway is reordered into its true time position and the affected span revalidated, while implausible timestamps are caught rather than silently trusted. Combined with disciplined source timestamping, that keeps a Merobix timeline strictly ordered and consistent even though the data feeding it arrives in fits and starts from links that fail all the time.
The most common cause is buffering: a field device stores readings during a comms outage and delivers the backlog when the link returns, so those values are older than what was collected live in the meantime. Retries and redundant delivery paths also produce late arrivals, and clock skew on an unsynchronized device can make its data appear out of order or land at the wrong point on the timeline. Buffering and retries are benign if handled well; clock skew is a defect to fix at the source.
Anything that consumed the stream in arrival order can become inconsistent. Compression already chose which points to keep from the neighbors it had, so a late insertion can leave the span inconsistent; calculated tags, totalizers, and rolling aggregates that already ran are now wrong; and if the historian stores the point in arrival order rather than timestamp order, queries see time jump backward. Correct handling reorders by timestamp and revalidates the affected data so the timeline stays trustworthy.
Not as a rule - much of it is legitimate buffered telemetry that should be accepted and reordered into place. But a point whose timestamp is implausibly old, far beyond any reasonable buffer or inside a sealed retention period, is better flagged or rejected, because it more likely reflects a clock fault than real history. Good historians accept genuine late data while catching timestamps that cannot be true.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.