Signal
Many devices missed heartbeats together
That pattern is unlikely to be dozens of independent hardware failures.
Playbook case study - Network outages
Case study: a customer fleet drops offline at once.
A cluster of remote gateways stops checking in and the customer wants to know whether to dispatch technicians. Use Dataplicity alerts, inventory, and last-known logs to prove whether this is device failure, regional connectivity, or account impact.
- Scope outage by network cohort, customer, and region.
- Compare offline devices with backup connectivity cohorts.
- Use logs and events to separate provider issues from device faults.
- Attach evidence before updating customers.
What the operator knows
A heartbeat alert fired for multiple devices at the same time.
Context
The affected units share a connectivity tag
The fleet has tags like connectivity:starlink, region, customer, and device class.
Decision
Support must decide whether to dispatch
The answer depends on whether evidence points to field hardware or provider state.
CLI investigation walkthrough
Start from the alert, scope the cohort, then collect customer-safe evidence.
01 - Alert
Inspect the outage alert
The alert gives the first affected cohort and incident link.
$ dataplicity alerts show <alert> --include incident,cohort,devices
incident=<incident>
cohort=connectivity:starlink
affected_devices=31
first_seen=09:12The investigation starts with a fleet pattern, not a single device guess.
02 - Scope
Compare network cohorts
If backup LTE devices stayed online, the evidence points away from the application or device class.
$ dataplicity devices list --customer <customer> --group-by network,status
NETWORK OFFLINE ONLINE
connectivity:starlink 31 4
connectivity:lte 0 29
lan 0 12The outage is isolated to one connectivity cohort, so dispatching hardware technicians is premature.
03 - Logs
Look for last-known network errors
Last-known logs show whether devices saw modem, DNS, or route failures before they went offline.
$ dataplicity logs query --tag connectivity:starlink "modem OR route OR dns" --last 2h
31 devices matched
09:11 <device> modem: link lost
09:11 <device> route: default gateway unreachableThis uses stored log evidence from before the outage; live remote commands require the device to be online in Dataplicity.
Operational conclusion
Dataplicity turns a noisy offline event into a specific next move.
Do not dispatch
Hold field visits until provider status is confirmed
The CLI evidence shows this is a shared network cohort issue, not isolated device failure.
Escalate
Send provider escalation with affected count
The incident contains device count, customer, region, and log signatures.
Communicate
Publish a customer-safe status note
Status pages can say connectivity provider degradation while internal logs remain private.
Diagnose network cohorts, not individual devices.
Use Dataplicity to connect alerts, logs, device tags, incidents, and customer updates.