Signal
The customer reports field impact
You have an incident, a customer name, and maybe one device, but not the full affected cohort or likely cause.
Playbook - Runbooks
Case study: support must decide whether a field failure needs dispatch.
A customer reports devices failing at a remote site. For devices that are online in Dataplicity, use alerts, logs, customer, warranty, and remote-access evidence to build a repeatable runbook before sending a technician.
- Start from an incident or affected cohort.
- Collect logs, status, and remote command output from online devices.
- Attach findings to the incident timeline.
- Preserve an audit trail for support and warranty decisions.
The support scenario
A remote-site escalation needs a repeatable path from alert to evidence to action.
Risk
Every responder debugs differently
Without a runbook, teams rerun different checks and lose the evidence needed for customer follow-up.
Goal
Build a CLI-backed response path
Collect status, logs, remote diagnostics, and incident notes in a consistent order once the device is online in Dataplicity.
CLI runbook walkthrough
Use one flow for triage, diagnosis, action, and evidence capture.
01 - Triage
Start from the open incident
The incident gives alert source, affected customer, and current responder ownership.
$ dataplicity incidents show <incident> --include alerts,devices,customer
severity=critical
customer=<customer>
affected_devices=18
primary_alert=heartbeat_missingThe runbook starts with the scope Dataplicity already knows.
02 - Cohort
List affected devices and context
Group by class, customer, network, or tag before deciding what failed.
$ dataplicity devices list --incident <incident> --group-by class,network,status
CLASS NETWORK OFFLINE ONLINE
<class> <network> 18 42
<class> backup-lte 0 37The operator can see whether the issue is isolated to a network cohort or customer site.
03 - Evidence
Collect logs and a safe remote check
Attach output to the incident so the next responder does not need to rerun it.
$ dataplicity logs query --incident <incident> "error OR timeout" --last 30m --save-evidence
saved_evidence=<evidence>
matches=64
top_signature="modem: registration denied"The incident now has a searchable evidence bundle tied to device identity.
Operational conclusion
Turn a one-off fix into a reusable response path.
Document
Attach the command sequence to the incident
The exact checks become a runbook for the next responder and an audit trail for the customer.
Automate
Promote safe checks into scheduled tasks
Recurring health checks can run against the same cohort before customers notice the next issue.
Communicate
Publish only customer-safe facts
Status pages can share the conclusion while internal diagnostics stay private.
Connect runbooks to live device evidence.
Make every incident response repeatable from alerts through logs, remote checks, and customer updates.