What are the guarantees and limits of telemetry delivery?

Dataplicity telemetry is suitable for product state, monitoring, diagnostics, customer-visible measurements, and operational history. Do not assume it is an exactly-once financial or legal event ledger.

If losing, duplicating, or reordering a record would create an incorrect business outcome, keep a durable application-owned journal and reconcile against an authoritative backend.

Start from the consequence of losing one record

Ask:

If this record never reaches the cloud, what breaks?

For a temperature sample, the answer may be “a chart has a small gap.” For a fuel transaction or credit consumption event, the answer may be “money or entitlement is wrong.” Those are different engineering problems.

Telemetry is not the same as a transaction log

A telemetry pipeline commonly has to tolerate:

devices going offline;
local queues filling;
application or agent restarts;
repeated publication;
variable network latency;
out-of-order arrival across reconnects or multiple producers.

Design the consumer for the documented delivery contract rather than assuming ideal network behaviour.

The current device data and control contract is the source of truth for supported semantics and limits.

Use a device-owned durable journal for critical events

For business-critical events, a strong pattern is:

text

physical/business event
        |
        v
local durable journal
        |
        +----> local product continues offline
        |
        v
publish/synchronise to cloud
        |
        v
authoritative backend reconciles and acknowledges

The device can retain an application-specific event identifier until the authoritative system has accepted it.

This gives you domain-level control over:

deduplication;
retry;
ordering where required;
reconciliation;
retention during long outages;
flash-write policy;
acknowledgement and deletion.

Flash wear is part of the design

Do not turn every high-frequency sensor sample into a synchronous durable flash write merely because offline operation exists.

Choose persistence based on consequence:

disposable/high-rate measurements can often tolerate bounded buffering;
state changes may be checkpointed;
financially or operationally critical events may need durable append-only storage;
batch writes and sensible fsync policy can reduce wear;
hardware with limited flash endurance may need a different persistence strategy.

Dataplicity cannot choose the correct durability trade-off for your product without knowing the consequence of losing the event.

Give events stable IDs when duplicates matter

If a receiver must distinguish a retry from a new event, publish a stable application event/transaction ID.

For example:

json

{
  "transaction_id": "site-17-device-4-0000182381",
  "occurred_at": "2026-08-29T02:15:04Z",
  "quantity_l": 87.4
}

The authoritative consumer can use transaction_id for idempotent processing even if transport retries occur.

Separate current state from event history

Some values are best modelled as current state:

current temperature;
current operating mode;
current tank level;
current software version.

Other facts are events:

alarm raised;
operator approved action;
transaction completed;
door opened;
software update failed.

Do not reconstruct a financial or audit ledger from a latest-value stream when the domain requires immutable event history.

Offline queues are bounded resources

No edge device has infinite storage. Define what happens when an outage exceeds the amount of telemetry you can buffer.

Options include:

drop oldest non-critical samples;
reduce sample cadence;
aggregate locally;
preserve critical events while discarding low-value samples;
alarm locally when storage pressure is high;
keep a separate durable journal for the events that cannot be lost.

Make that behaviour part of the product design rather than an accidental result of disk exhaustion.

Verify time semantics

A delayed event should preserve the time it occurred on the device where that matters. Do not substitute cloud receipt time for event time without understanding the consequence.

Also decide how your product handles an incorrect device clock. If trustworthy timestamps are critical, clock/NTP health is itself an operational dependency worth monitoring.

Match telemetry to the use case

Use case	Dataplicity telemetry	Extra mechanism
Current sensor value in portal	Strong fit	Stale/offline state handling
Operational trends	Strong fit	Sampling/retention policy
Alert input	Strong fit	Define stale/missing behaviour
Diagnostics evidence	Strong fit	Correlate with logs/version/state
Customer usage estimate	Often	Domain validation
Financial settlement	Not sufficient as the sole ledger	Durable journal + authoritative backend
Safety interlock	Not appropriate as cloud authority	Local control system

What are the guarantees and limits of telemetry delivery? ​

Start from the consequence of losing one record ​

Telemetry is not the same as a transaction log ​

Use a device-owned durable journal for critical events ​

Flash wear is part of the design ​

Give events stable IDs when duplicates matter ​

Separate current state from event history ​

Offline queues are bounded resources ​

Verify time semantics ​

Match telemetry to the use case ​

Related ​