A historian normally receives data with current timestamps, but there are legitimate reasons for data to arrive late, carrying timestamps from the past: a collector draining a buffer after an outage, a manual import, or a device that was offline. The backfill window is the configurable rule that says how far into the past the archive will accept such writes before it starts rejecting or shifting them. It exists to protect the archive from arbitrary rewriting of history, but set too narrow it can silently discard data you genuinely wanted. This page explains what the backfill window is, why it exists, and how its boundary quietly gates every late-arriving value.
Historian backfill window in one line: A historian backfill window is the configurable span of past time within which the archive will accept writes carrying older timestamps. Values timestamped inside the window are stored in their correct historical position; values older than the window are rejected or have their timestamps shifted to the boundary. The window protects archive integrity by limiting how far back history can be altered, but set too narrow it silently drops legitimate late data such as a long buffer recovery.
A historian is meant to be a faithful record of what happened, which means it has to be cautious about accepting values that claim to belong to the past. If it accepted a write for any timestamp, no matter how old, then anything, a misconfigured device, a clock error, or a bad import, could reach back and alter history that had already been recorded and relied upon. The backfill window is the archive's defence against this: it defines a bounded region of recent past time within which late-arriving data is welcome, and beyond which the archive refuses to let its record be rewritten. The window is, in effect, the archive drawing a line about how far back it is willing to be edited.
The reason this is a window rather than a flat rule is that late data is normal and legitimate up to a point. A collector recovering from an outage delivers values that are genuinely old but genuinely correct, and the archive should place them in their true historical position, which requires accepting past timestamps. The backfill window exists precisely to accommodate this normal lateness while still drawing a boundary, so that ordinary recovery and import work, but arbitrary rewriting of distant history does not. The width of the window is where the archive balances these two needs: wide enough for real late data, narrow enough to protect established history.
It is worth separating this acceptance-window boundary from the broader idea of filling gaps in history. Filling a gap is the goal; the backfill window is the gate that decides whether a given late value is allowed through to do that filling. Two writes can both be attempts to fill a gap, and one may be accepted while the other is rejected purely because of where its timestamp falls relative to the window. Understanding the window is understanding the specific rule that governs which past-timestamped writes succeed, independent of the general intent to backfill.
When a value arrives with a timestamp older than the backfill window allows, the archive does not simply store it where it claims to belong, and the two common behaviours are to reject it or to shift it. Rejection means the value is refused outright: it is not written at all, and unless something notices, it is simply lost. Shifting means the archive stores the value but moves its timestamp forward to the window boundary or to the current time, so the data is kept but no longer sits at its true historical position. Both behaviours protect the archive from having distant history rewritten, but they do so at a cost to the late data, and which one a historian uses is an important detail of its configuration.
Neither behaviour is free of danger, and both can mislead if not understood. A rejected value leaves a gap that looks exactly like data that never existed, so a genuinely captured measurement can vanish without trace if it arrived too late. A shifted value is arguably worse in some cases, because the data is present but at the wrong time, which can corrupt any calculation or trend that assumed the timestamp was accurate. A value that really occurred an hour ago but was shifted to now will misplace an event, distort an aggregate, or make a trend look wrong, all while appearing to be perfectly good data. Knowing whether your historian rejects or shifts is essential to interpreting what happened to late writes.
Because both outcomes can be silent, the crucial safeguard is visibility: the archive or the writing process should make it plain when a value fell outside the backfill window and was rejected or shifted, rather than letting it disappear or move quietly. A historian that logs or flags out-of-window writes gives operators a chance to notice that legitimate data was affected and to widen the window or re-import correctly. Without that signal, the boundary does its protective job invisibly, and the first sign of trouble is discovering that recovered or imported data is missing or misplaced with no obvious reason.
The practical failure mode of a backfill window is setting it too narrow for the lateness your system actually produces. If a collector can buffer through a multi-hour outage but the archive's backfill window only accepts data a short way into the past, then when that collector finally reconnects and drains its buffer, the oldest values in the backlog fall outside the window and are rejected or shifted. The buffer did its job perfectly, holding every value through the outage, and the window silently undoes that work at the last step by refusing the very data the buffer preserved. This is the classic, frustrating way a too-narrow window causes loss that no one anticipated.
The window therefore has to be sized against the real lateness the system can produce, which means the longest buffered recovery, the largest expected import, and any device that might come back online after a long absence. If a site's collector can hold a full day of data through an outage, the backfill window must comfortably exceed a day, or that recovery will be partly discarded at the boundary. Sizing the window is thus a companion decision to sizing the buffer: the buffer determines how much late data can exist, and the window determines whether the archive will accept it, and the two must be consistent or the effort spent on buffering is wasted.
For a distributed SCADA system, where remote sites can lose communications for extended and unpredictable periods, the backfill window is a quiet but decisive part of whether outage recovery actually completes. A field collector that survives a long outage only matters if the central archive will accept its full backlog when the link returns, which depends on the window being wide enough. A platform such as Merobix aligns its acceptance window with the buffering and recovery it provides, so that a genuine long outage recovers completely rather than having its oldest hours clipped at the boundary, and it makes out-of-window cases visible rather than silent. That alignment is what lets an operator trust that a recovered site's history is truly complete and not quietly truncated by an acceptance rule they never saw.
To protect the integrity of history it has already recorded. If the archive accepted a write for any timestamp no matter how old, a misconfigured device, a clock error, or a bad import could reach back and alter established history. The backfill window bounds a region of recent past time within which late data is accepted, so normal recovery and imports work while arbitrary rewriting of distant history is prevented.
It is either rejected or shifted, depending on the historian. Rejection refuses the value outright, so it is lost and leaves a gap that looks like data that never existed. Shifting stores the value but moves its timestamp to the window boundary or current time, so the data is kept but no longer at its true historical position, which can corrupt trends and aggregates. Knowing which behaviour your historian uses is essential to interpreting late writes.
Wide enough to cover the longest lateness the system can genuinely produce, including the longest buffered collector recovery, the largest expected import, and any device that might return after a long absence. If a collector can hold a full day of data through an outage, the window must comfortably exceed a day, or that recovery will be partly rejected at the boundary. Sizing the window is a companion decision to sizing the buffer, and the two must be consistent.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.