Keep collecting into a bounded local record store when the internet connection drops, if the installed system supports it. Show remote users that their information is aging. After reconnection, recover the history without presenting old readings as current conditions. Keeping data requires all three decisions, not just a reconnect button.
An outage can leave a working collector with useful observations that nobody elsewhere can yet see. The practical question is what gets stored, what remains unknown, and how the recovered records will be used. Agree on those rules before relying on the history.
Follow the record across the broken link
A collector reads approved measurement sources. Its buffer is temporary local storage for records awaiting transfer. A wide-area network connection carries those records to a remote service. These are separate parts of the path: losing the internet connection does not prove that collection has stopped.
- Observe: Read the source through its approved interface.
- Retain: Store the observation and its identity locally.
- Wait: Mark transfer pending while the link is unavailable.
- Receive: Record arrival at the destination separately.
- Reconcile: Decide how the record enters history and views.
This article assumes the collector, its power, source connection, and storage remain functional. Replacing a failed collector is a different problem. A remote viewer cannot establish those local conditions from silence alone.
Microsoft's IoT Edge offline guidance describes operation after an initial online synchronization. It limits message storage by retention settings and available disk space. This is a product capability with conditions, not a guarantee for every installation.
Keep observation time separate from arrival
A record needs to say when something was observed, not merely when an upload succeeded. Source time identifies the observation. Receipt time identifies arrival at the remote service. A late upload must preserve both so a reviewer can reconstruct the delay.
- Identity
- Site, measurement point, and a stable event ID.
- Source time
- Observation timestamp, time zone, and clock-quality status.
- Receipt time
- Destination arrival timestamp; unknown until received.
- Evidence
- Original value, units, measurement quality, and sequence where available.
Some devices supply timestamps; others require the collector to assign them. Document which happened. If the collector timestamps a read, say so rather than implying the sensor supplied an exact measurement time. Preserve uncertainty when a source clock is suspect.
Use an identity that survives transfer retries. A new upload attempt should not create a new observation. Sequence numbers can help explain ordering. Include a collector identity and recording session so a restarted sequence does not collide with earlier events. Do not silently replace an uncertain source timestamp with receipt time and call the result accurate history.
Decide what happens when storage runs out
Local storage is finite. A buffer can fill before a connection returns, and a retention rule can expire records even when space remains. Specify both the capacity boundary and the time boundary. Neither should be guessed from the size printed on an enclosure.
- Boundary
- Usable storage allocation and supported retention period.
- Pressure
- Buffer occupancy, oldest pending record, and rejected writes.
- Full or expired
- Document which records are rejected, removed, or retained.
- Loss evidence
- Preserve known missing intervals and mark uncertain loss explicitly.
AWS's Greengrass stream documentation distinguishes file persistence across core restarts from memory storage. It also defines maximum-size behavior and a retention window that is not an immediate deletion policy.
Rejecting new records preserves older evidence but loses later observations. Removing older records preserves newer evidence but loses earlier history. Neither policy suits every use. The responsible operations and application owners should agree what evidence matters, how loss becomes visible, and who reviews it.
Separate transfer acknowledgment from acceptance into the historical store. A successful network send alone does not establish that the destination saved a usable record. Define what evidence permits buffer cleanup, then apply the agreed retention policy.
Assess actual record types, bursts, other disk users, storage wear, and the time needed to transfer retained data. There is no universal buffer size or outage duration. If loss accounting is incomplete, report the extent as unknown rather than claiming a complete interval.
Show the blind period on the screen
Remote users need the age of the last usable observation and the state of the connection. A page that still loads can still be blind. Label the last-known reading as historical once it exceeds the freshness requirement agreed for that use.
- Last known
- Observation time and quality of the last accepted reading.
- Freshness
- Its age now, with current, stale, or unknown status.
- Connection
- Last contact and present delivery availability.
- Coverage
- Missing intervals and records still awaiting reconciliation.
Do not draw a smooth line across missing observations without identifying the gap. A missing tank-level reading is neither zero level nor evidence of normal conditions. A known old value can remain visible with its timestamp, but its display must not imply a fresh measurement.
A local screen may have newer information if it can read the functioning collector. The remote screen cannot borrow that certainty. Existing qualified control and protection systems retain equipment authority. The monitoring design provides no new ability to notify a remote person while its delivery path is offline.
Recover a tank's history without resetting the present
Hypothetical worked scenario
Consider water-storage tank WT-04 with an approved read-only level collector and a central historical store. The site and records below are invented. The link drops at 10:00 and returns at 10:15. The collector continues storing observations. All times use UTC on October 20, 2026.
| Event ID | Source time | Receipt time | Disposition |
|---|---|---|---|
| R440 | 09:59:40 | 09:59:42 | Before outage. |
| R443 | 10:15:04 | 10:15:06 | New observation. |
| R441 | 10:04:00 | 10:15:10 | Late history. |
| R442 | 10:09:00 | 10:15:12 | Late history. |
| R441 | 10:04:00 | 10:15:14 | Repeated delivery. |
At 10:10, the remote view still has R440, even though newer observations exist locally. At reconnect, this invented delivery path accepts R443 before the backlog. It is an example of arrival order, not a promise that a particular product prioritizes current traffic.
R441 and R442 fill historical positions using source time. They must not overwrite the newer R443 merely because they arrived later. Record repeat delivery attempts separately; do not change R441's original receipt time to its retry time. R443 itself needs acceptable quality and age before a current view uses it. A restored connection alone cannot certify a current tank condition.
Give each recovered record a clear destination
Reconciliation means comparing received records with what is already stored and explaining unresolved differences. Use ordinary software rules for this work. Keep the central history, current view, and notification workflow separate so one successful upload cannot silently update all three.
| Record condition | History treatment | Current view or workflow |
|---|---|---|
| Fresh, valid observation | Store with source details. | Eligible under freshness rules. |
| Valid late observation | Place at source time. | Do not replace newer evidence. |
| Same identity and content | Recognize the repeat. | Do not repeat its effect. |
| Same identity, different content | Preserve the conflict. | Hold for investigation. |
| Missing or uncertain time | Retain uncertainty. | No invented current value. |
| Historical alarm event | Retain event and delivery evidence. | Review outcome separately. |
AWS IoT Core's MQTT documentation allows repeated message deliveries. MQTT is a messaging protocol. Successful transport therefore does not establish that an observation is new.
Recognizing a repeated R441 should avoid double-counting it in a report. If a separate tank alarm record arrives late, preserve its original time. Do not present it as a new condition or automatically replay an old notification. If delivery or acknowledgment is unconfirmed, the alarm outcome remains unknown.
Close the outage with an honest history
The application maintainer checks transfer and conflicts. The operations reviewer checks what the recovered history can support. The central historical store holds accepted records; a reconciliation note records gaps, unresolved evidence, and review status.
- Account: Compare retained, accepted, pending, and known lost records.
- Explain: Keep gaps and timestamp uncertainty visible.
- Review: Assign conflicts and alarm outcomes to an owner.
- Record: State whether history is complete, partial, or unknown.
If retained records and central receipts do not agree, leave the interval unresolved and assign an investigation. The operations owner accepts the report's stated coverage and limitations, rather than approving completeness from an empty transfer queue. A report issued before recovery should retain its earlier coverage status; record later corrections explicitly.
A gap in WT-04's history stays a gap unless valid observations recover it. Optional AI can summarize the reviewable history and open questions, preserving missing intervals and linking to records. It cannot infer a normal level, authorize equipment actions, or approve an alarm response.
Start by completing the disposition matrix for one measurement point with its operations owner and application maintainer. Agree on retention, freshness, and unresolved-loss handling. That gives the team a concrete record policy to assess before undertaking a detailed reconnect acceptance test.