What happens when a device is offline?

A disconnected device cannot be remotely accessed or receive live cloud commands until it reconnects. Your product must therefore remain safe and useful without Dataplicity or Internet connectivity.

Different Dataplicity features have different offline semantics. Do not treat “offline support” as one blanket guarantee.

At a glance

Capability	While device is offline
Remote Shell / live support	Unavailable until reconnect
Live diagnostics that require the device	Unavailable until reconnect
Connection-state monitoring	Device is shown as offline according to monitor/heartbeat behaviour
Product telemetry	Local buffering may retain data within documented limits; do not assume exactly-once delivery
Desired settings	Cloud desired state can remain authoritative; local application applies/reports when connected according to the documented contract
Remote actions/commands	Current behaviour depends on the command path and published production limits; do not assume an offline command will later execute
Product Applications cloud records/processes	Cloud-side state can continue independently where the workflow does not require the device
Offline datasets	Specifically designed to place selected application data on-device for local use
Your product's core control logic	Must continue locally by design

For exact current limits, use Device data and control contract and Production limits as the contract of record.

Design the product offline-first where it matters

The safest architecture is:

cloud available      -> more visibility, configuration, coordination and support
cloud unavailable    -> product remains locally safe and performs its essential job

Examples:

• a tank monitor continues measuring and recording level locally;
• an HVAC controller continues its current schedule and safety limits;
• an access system uses a locally available authorisation dataset;
• a camera continues recording according to its local policy;
• a gateway continues forwarding local industrial traffic if that is its job.

Dataplicity should enhance those products, not become a hard dependency for their basic safe operation.

Telemetry during an outage

The device-side product path can buffer telemetry within its documented queue/storage limits, then resume delivery after connectivity returns.

But two rules matter:

1. A finite local queue is not an accounting ledger. If data is materially important, keep an application-owned durable journal as well.
2. Do not assume exactly-once or strict global ordering unless the public contract explicitly guarantees it. Include stable event IDs/timestamps where your backend needs to deduplicate or reconstruct order.

For environmental samples, fleet health, temperatures, process metrics, and similar operational telemetry, this is normally sufficient when designed correctly.

For legally, financially, or operationally irreplaceable records, maintain your own durable record and use Dataplicity as a transport/operational layer rather than the sole source of truth.

Settings while offline

Settings are best treated as desired state, not as proof that the device has already changed.

A safe pattern is:

1. cloud records desired value;
2. device reconnects and receives/reads desired value according to the product contract;
3. local application validates it;
4. local application applies it if safe;
5. device reports actual/applied state;
6. UI distinguishes desired from reported state.

That distinction matters. “Set target temperature to 4°C” does not mean the local controller has actually accepted or reached 4°C.

Commands/actions while offline

Do not build a critical workflow around the assumption that an action clicked while a device is offline will inevitably execute later.

The current public production contract should be checked for the exact command path you are using. At minimum, distinguish:

• command created in cloud;
• accepted/queued by Dataplicity;
• delivered to the device;
• accepted by your local application;
• completed or failed.

Until a final execution result exists, the remote request is not proof that a physical action occurred.

For consequential actions, your local application should also enforce:

• idempotency;
• expiry/TTL;
• valid current-state checks;
• authorisation/domain rules;
• a final result/acknowledgement.

See Production limits.

Offline datasets are a different mechanism

Product Applications can expose selected data to a device for local use through offline datasets.

This is useful for cases such as:

• approved tags or credentials;
• site configuration;
• tariff/config tables;
• bounded product reference data;
• access or entitlement information that must be available during an outage.

The device application still owns the local decision. The dataset gives it current synchronised input; it does not move your safety or financial authority into the cloud.

What happens when connectivity returns?

A production device should recover without manual intervention.

Test:

• reconnect after seconds, hours, and days offline;
• reconnect after WAN address changes;
• reboot while offline and then reconnect;
• telemetry queue drain;
• desired/reported settings reconciliation;
• expired command behaviour;
• stale offline-data handling;
• clocks that have drifted while disconnected.

Weak networks create more edge cases than clean lab networks. Test with a real mobile or customer-site connection if that is how the product will ship.

What should the customer portal show?

Do not hide disconnection.

A useful customer experience shows:

• online/offline state;
• last-seen time;
• age of the last product reading;
• whether displayed data may be stale;
• whether a control is unavailable because the device is disconnected;
• whether a desired setting is still pending application.

This prevents a stale value from looking like a current physical measurement.

Related

• Device data and control contract
• Production limits
• What exactly runs on my device?
• Where should business logic live?
• Product Applications