Your sensor may be accurate.
Your network may eventually deliver every reading.
Your database may contain every event.
And the graph can still be wrong.
The reason is simple: distributed IoT systems deal with several different notions of time, and it is easy to collapse them into one.
Suppose a temperature sensor records 86°C at 02:13.
The site is offline.
The event reaches the cloud at 08:17.
If your dashboard plots that measurement at 08:17, no data was technically lost. But the system now claims the temperature was 86°C six hours later than it actually was.
That can matter more than losing the reading entirely.
Event time and receive time are different facts
At minimum, an IoT event may have:
Occurrence time — when the physical event or measurement happened.
Local persistence time — when the edge system accepted it.
Cloud ingestion time — when the cloud received it.
Processing time — when some downstream service handled it.
All four can be legitimate timestamps.
They answer different questions.
For real-time systems with stable connectivity, these times may be so close that nobody notices the distinction. An outage makes it visible immediately.
After several hours offline, thousands of events can reach the cloud in a few minutes. If ingestion time is used as event time, the dashboard may show a huge burst of activity that never actually happened.
This affects more than charts
Incorrect timing can change automated behaviour.
Imagine a maintenance system looking for three high-vibration readings within ten minutes.
The actual events occurred at:
10:03 10:17 11:42
They arrive together after a network outage at:
13:01:04 13:01:05 13:01:06
A system using ingestion timestamps may conclude that all three occurred within two seconds.
The original sensor data is correct. The interpretation is wrong.
The same problem can affect alerts, SLA calculations, sequence analysis, anomaly detection and machine-learning features built from historical data.
“Eventually delivered” is therefore not enough if the timing context is lost along the way.
Backlog draining makes the problem obvious
Suppose a device has been disconnected for six hours and accumulated 20,000 readings.
When connectivity returns, those events may arrive much faster than they were created.
That is exactly what should happen: the backlog is being drained.
But the receiving system needs to know that the burst represents historical data.
Otherwise an outage produces a second incident in the analytics layer: six hours of activity appear compressed into the recovery window.
The event itself should carry the original occurrence time. Cloud timestamps can then be stored alongside it rather than replacing it.
This also makes latency measurable.
If OccurredAt is 10:03 and ReceivedAt is 13:01, the system knows the event spent almost three hours somewhere before cloud ingestion.
That is useful operational evidence.
Device clocks are not perfect either
Preserving occurrence time introduces another problem: the source clock may be wrong.
IoT devices can drift. Some reboot without reliable time until they synchronise. Others operate for long periods without access to a trusted time source.
This does not mean occurrence timestamps are useless.
It means their provenance matters.
For some systems, precise UTC time is essential. Others mainly need correct ordering within one device. Some can tolerate seconds or minutes of clock error.
The requirement should match the use case.
If timing is safety-critical or financially significant, clock synchronisation deserves the same attention as delivery.
If telemetry is used for general trend analysis, less precision may be perfectly acceptable.
Duplicates can distort data too
A lost acknowledgement can result in the same event being delivered again.
For a command or state transition, duplicate processing may create obvious problems.
For telemetry, duplicates can be quieter.
One reading appearing twice may barely affect a graph. Thousands of duplicated measurements can skew counts, averages, anomaly detection or billing based on event volume.
Stable event identity makes it possible to distinguish:
two measurements with the same value
from
the same measurement delivered twice.
Those are not the same thing.
“Latest value” is a different model
Some telemetry systems do not care about historical events at all.
They care about current state.
If the only question is “what is the temperature now?”, then a six-hour-old reading may not need to be delivered when connectivity returns. Sending it could even be counterproductive.
This is why reliability should not automatically mean preserving every message forever.
A current-state stream and an event history have different semantics.
A robust IoT architecture should know which one it is dealing with.
Data integrity starts before the database
It is easy to think of data quality as something handled later by analytics or ETL.
For IoT, some of the most important context is created at the source.
What happened?
When did it happen?
Which device produced it?
Is this a new logical event or a resend?
How long did it take to reach the cloud?
Once that information is lost, downstream systems can only guess.
Reliable delivery is therefore not just about ensuring bytes eventually arrive.
The event needs to arrive with enough context to still mean the same thing.