Docs

Investigate a fleet that goes offline together.

Worked scenario: several gateways stop checking in together. Use device inventory, alerts and collected logs to narrow the cause and decide what to check before sending a technician.

Back to playbooks

Get the install command by email. Remote access is free on one device. Pricing

  • 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.

Signal

Many devices missed heartbeats together

That pattern is unlikely to be dozens of independent hardware failures.

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.

Open alert context
$ dataplicity alerts show <alert> --include incident,cohort,devices
incident=<incident>
cohort=connectivity:starlink
affected_devices=31
first_seen=09:12

The 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.

Group by network
$ dataplicity devices list --customer <customer> --group-by network,status
NETWORK                 OFFLINE  ONLINE
connectivity:starlink   31       4
connectivity:lte        0        29
lan                     0        12

The 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.

Search cohort logs
$ 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 unreachable

This 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.

Back to playbooks