Appearance
Status notifications
A device changing from online to offline is useful evidence, but it is not always an incident. Customer networks restart, mobile links move between cells, and devices may intentionally sleep.
Dataplicity combines presence with device context so teams can distinguish expected churn from a support problem.
Build a useful signal
- Group devices by operational meaning. Apply customer, site, product, environment, and rollout-cohort tags.
- Define expected behaviour. Decide how long each class of device can remain silent before a response is needed.
- Monitor the service, not only the connection. Add checks for the process, endpoint, storage, or telemetry that indicates the product is working.
- Route alerts to an owner. Use alert rules and integration webhooks to send actionable events into the system your team already watches.
- Link the response runbook. Include the device identity, customer/site context, recent logs, and the first safe diagnostic action.
Presence and health answer different questions
| Signal | Question it answers |
|---|---|
| Presence | Has Dataplicity heard from this device recently? |
| Endpoint monitor | Is the device service responding as expected? |
| Device monitor | Is a local health condition within its safe range? |
| Logs | What changed before or during the problem? |
| User-impact state | Does this problem affect a customer-facing service? |
Treat these as layers of evidence. A device can be online while its application is unhealthy, or briefly offline without customer impact.
Design the response
Start with notification-only rules. Once the signal is reliable, add a controlled workflow:
- Open the affected fleet or customer scope.
- Review recent logs and monitor history.
- Run a non-destructive diagnostic.
- Use remote access when deeper investigation is required.
- Record remediation and customer impact.
Automate corrective actions only after the detection rule has proven stable and the action is safe to retry.