There is a meaningful difference between a tag that was flat at a value and a tag for which the historian has no idea what the value was. A data gap is that second case: a stretch of time where the archive holds no valid data because collection stopped. This guide explains how historians mark real gaps, how retrieval behaves across them, and why a gap must never be quietly interpolated as if the signal simply held steady.
Data Gaps in Historians in one line: A data gap in a historian is an interval where no valid values were collected - because a collector was down, communication was lost, or the source stopped answering - and the archive records the absence explicitly rather than filling it. Correct handling keeps the gap distinct from a stale flatline so trends and calculations do not treat missing data as a real, unchanging reading.
The dangerous failure is when a lost signal looks like a real one. If a device stops responding and the historian keeps repeating the last value it saw, a trend shows a perfectly flat line that appears to be legitimate steady operation. That is a stale flatline: the number is present but frozen and no longer means anything. A genuine gap is the opposite - the historian knows collection stopped and refuses to invent a value at all.
Historians distinguish these by writing an explicit marker when collection is interrupted. When a collector shuts down cleanly, or detects that a source has gone unreachable, it inserts a point carrying a bad or no-data quality that closes the previous good value and opens the gap. When collection resumes, another point reopens the trend. Between those two markers, the archive contains nothing, and it says so.
This is why a gap is not the same as a zero. A flow tag reading zero means the historian is confident the flow was zero. A gap on that same tag means the historian does not know what the flow was. Treating one as the other is how phantom shutdowns and impossible spikes end up in reports - a real hazard when the number feeds production accounting.
When you query a trend that spans a gap, a well-behaved historian returns the gap boundaries so the client can break the line rather than draw straight through it. The visual result is a trend that stops at the last good value, shows empty space, and resumes at the first value after recovery. That empty space is honest: it tells the operator that the record is missing, not that the process sat still.
The rule that matters most is that a gap must not be interpolated across. Interpolation and linear reconstruction are valid for compressed data, where the historian genuinely knows the endpoints and the deviation bound guarantees the path between them. A gap has no known endpoints inside it, so drawing a line across it invents data. Aggregations behave the same way: a good historian excludes gap intervals from averages, minimums, maximums, and totals rather than counting missing time as if it held a value.
Some retrieval modes let you choose how gaps are surfaced - returning explicit gap markers, returning nothing for the interval, or returning the last known value carried forward with a bad quality attached. The safe default for analysis is the one that keeps the gap visible, because a carried-forward value used without checking its quality is exactly how missing data silently contaminates a calculation.
Remote oil and gas sites produce gaps constantly. A wellpad on cellular loses its link in bad weather, a solar-powered RTU browns out overnight, a collector is restarted during maintenance. Each of these leaves a real gap in the record, and a SCADA historian that handles them correctly is what lets an operator trust the trend they are looking at instead of mistaking a dead link for calm operations.
The interaction with backfill is important. Many gaps are temporary - the link returns and buffered data flows in to fill the missing interval, converting the gap into real history. But some gaps are permanent: no device was buffering, so the data is simply gone. A good platform keeps the gap marked until it is genuinely filled, rather than papering over it, so a permanently missing interval never masquerades as recorded data.
For a cloud SCADA platform like Merobix, this shows up directly in the operator experience. Trends break cleanly where a remote site went dark, aggregates ignore the missing time, and once a gateway reconnects and backfills its buffer, the gap closes into a continuous record. The point is honesty: the operator can always tell the difference between a quiet process and a lost connection.
The collector writes an explicit marker when collection is interrupted - a point with bad or no-data quality that closes the last good value and opens the gap. Everything between that marker and the point that reopens the trend is recorded as missing. A real value, even a flat one, carries good quality, so the historian and its clients can tell an honest steady reading from an interval where nothing was collected.
Interpolation assumes you know the values at both ends of an interval and can reasonably estimate what happened between them. A gap has no valid data inside it and often no trustworthy value at its edges, so drawing a line across it fabricates history that never existed. This can hide a shutdown, invent flow that was not measured, or corrupt an average, which is why gaps should be shown as gaps and excluded from aggregations.
No. A zero is a real measured value - the historian is confident the reading was zero. A gap means the historian does not know what the value was because collection stopped. Treating a gap as zero can invent a false shutdown, and treating a zero as a gap can hide a genuine one, so historians keep the two strictly separate through quality markers.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.