Late Data Handeling
Late data is data that arrives at the Historian with a timestamp earlier than the most recently stored point — out of chronological order.
Overview
Late data is data that arrives at the Historian with a timestamp earlier than the most recently stored point — out of chronological order. This happens regularly in industrial deployments: a field device has a clock that drifts, a Collector goes offline and buffers data locally, or a store-and-forward replay delivers a backlog of measurements after a network outage.
Timebase accepts and stores late data automatically. The Late Data Tolerance setting gives you control over how far back the Historian will accept late data, and lets you discard small clock-skew duplicates without losing genuine backfill data.
How late data works
Storage and the .late file
When a data point arrives with a timestamp that falls inside a completed hourly block, the Historian cannot write it directly into that block — the block may already be in use by a reader. Instead, the Historian buffers the late point in a temporary .late file alongside the corresponding .data block. During the next maintenance cycle (approximately every minute), the Historian merges all pending .late files back into their .data blocks and deletes the .late files. After merging, the data is available for queries.
You can monitor late data arrival using the Dataset.Writes.Late system tag, which reports the rate of late data ingestion in points per second.
Late Data Tolerance
The Late Data Tolerance setting defines a clock-skew window in milliseconds. Its purpose is to distinguish genuine late data (a backfill) from clock-skew noise (a device whose clock is slightly off and repeatedly sends timestamps a few milliseconds in the past).
| Scenario | Behaviour |
|---|---|
| Data arrives with a timestamp within the tolerance window of the most recent stored point | Treated as clock-skew or a duplicate. Discarded. |
| Data arrives with a timestamp beyond the tolerance window (further back in time) | Treated as genuine late data. Accepted and stored via the .late buffer. |
Example: With Late Data Tolerance set to 100 ms, a point arriving 50 ms before the most recent stored timestamp is discarded as clock noise. A point arriving 5 seconds before the most recent stored timestamp is accepted as a genuine backfill point.
How to configure
In the Historian browser (Dataset Editor)
- Navigate to the Historian at
http://<historian>:4511. - Open the Datasets view.
- Click the edit icon for the dataset you want to configure.
- Find the Late Data (ms) field and enter the tolerance in milliseconds.
- Save the changes.
The Datasets grid also displays the current Late Data Tolerance for each dataset in the Late Data (ms) column.
Via the REST API
Set ldt (Late Data Tolerance in milliseconds) when creating or updating a dataset:
POST /api/datasets/{datasetId}
Content-Type: application/json
{
"ldt": 100
}
The same field is returned in GET /api/datasets and GET /api/datasets/{datasetId} responses.
Choosing a value
| Value | When to use |
|---|---|
0 (default) |
All out-of-order data is accepted. Use when data sources have accurate clocks and you want all backfill data stored. |
100 (100 ms) |
A reasonable starting point for sources with minor clock jitter. Discards duplicates within 100 ms without filtering genuine backfills. |
| Higher values | Use for sources with known significant clock drift. Set to the maximum expected clock error for that data source. |
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
Dataset.Writes.Late is non-zero during normal operation with no known outage |
A data source has a clock that drifts behind and is sending timestamps slightly in the past | Check which Collector is sending late data and which data source it is connected to. Set the Late Data Tolerance to slightly above the observed clock drift to discard those duplicates. If the drift is significant, fix the clock on the data source device |
| Late data is being discarded when it should be accepted — backfill data is missing | Late Data Tolerance is set too high and is filtering out genuine late data alongside clock-skew noise | Reduce the Late Data Tolerance or set it to 0 to accept all late data. The backfill will be replayed the next time the Collector reconnects |
.late files remain on disk for an extended period |
The Historian maintenance cycle has not merged them yet (runs approximately every minute), or the merge was interrupted by an unexpected shutdown | Allow the Historian to run — merges happen automatically. If .late files persist for more than a few minutes with no new data arriving, check the Historian log files for merge errors. The Maintenance.Failure system tag becoming active at the same time confirms a maintenance cycle error |
After a store-and-forward replay, the Historian shows Dataset.Writes.Late elevated for a long time |
A large volume of backfill data is being replayed. This is normal and expected | No action required. The elevated rate will return to zero once the backfill is complete. Do not stop the Collector during replay as this may cause data loss from the buffer |