Appearance
Device offline #
Use this guide when a previously connected device appears offline in Dataplicity. An offline device cannot accept a new Remote Shell session, so begin with cloud-side and peer evidence.
Before you start #
Confirm the device identity from a physical label, installation record, customer report, or existing device record. Note when it was last known online and whether anyone has local access. Do not interrupt connectivity on a production device to test this procedure.
1. Establish the scope #
Check whether the problem affects:
- one device;
- several devices at the same customer, site, network, ISP, class, or rollout cohort; or
- the wider service, using the Dataplicity status page.
Use device monitors, the device timeline, and fleet tags to compare the affected unit with peers. A single missing device and a site-wide outage need different recovery paths.
2. Read evidence that remains available #
Record the last connection time and inspect recent timeline events, centrally collected logs, monitor history, recent fleet/software work, and available diagnostics. Look for a network, power, storage, clock, certificate, agent, or application change near the last successful connection.
Local application output is not proof that central log delivery succeeded. Likewise, an online peer does not prove that the affected device has power or a working route.
3. Choose the available recovery path #
Someone can reach the device locally #
Check power, the default route, DNS, system time, trusted CA certificates, available storage, and the service procedure for the installed agent generation. Use firewall requirements for permitted outbound destinations and agent operating guidance for release-specific service checks.
After correcting the local cause, wait for the same device record to reconnect. A new duplicate record is not recovery of the original identity.
Nobody can reach the device locally #
Remote Shell and Wormhole cannot open while the device is disconnected. Use site/network evidence and an authorised out-of-band management path if the product has one. Otherwise arrange local recovery. Do not open inbound firewall access or ask a customer to expose SSH as an improvised workaround.
Check it worked #
Verify all of the following:
- the original device record is online;
- its timeline shows a fresh connection;
- expected application/service evidence resumes;
- the relevant monitor recovers after its configured successful evaluations; and
- the customer-impacting function works independently of the connection indicator.
If it does not work #
| Symptom | Check | Safe next step |
|---|---|---|
| No peers at the site are online | Site power, upstream network, ISP or firewall change | Work through the site/network owner before changing one device |
| The device has a route but cannot reconnect | DNS, system clock, TLS interception and outbound destinations | Use the firewall and agent troubleshooting guides |
| A different device record appears | Provisioning or identity reuse | Stop repeated installation and reconcile the physical identity |
| It reconnects but the product is still broken | Application logs, service monitor and device diagnostics | Follow signal to verified recovery |
When escalating, include the organisation and device identifiers, distribution and architecture, approximate start time, recent changes, and redacted errors. Never include passwords, API keys, installer codes, or unnecessary customer data.