How did we miss the alert?
Nobody fired on the fleet condition. Host checks and single-site uptime never asked whether every currently-running Starlink device dropped together. Customers found it first.
Playbook - Integrated workflows
Without one platform, you stitch five tools - or hear about it from a customer.
Fleet condition
All running Starlink devices dropped offline
Without Dataplicity
Bolted-together chain
- 1Pingdom canary
- 2PagerDuty
- 3VPN shell
- 4incident.io
- 5Statuspage
Usual case No fleet-cohort alert — you find out when users complain.
With Dataplicity
One designed workflow
Device record
Fleet cohort monitor, phone alert, terminal, incident, and status share one device record.
Individual sites flake all the time. When every currently-running Starlink device in the fleet drops at once, that is a different class of fault - and bolted-together stacks almost never alert on it. Dataplicity makes that fleet condition a first-class workflow.
You already know this story
The night where every tool is “working,” and somehow you still do not know what is true.
Why is the canary fine?
Pingdom is green on the one box you remembered to watch. Everything else on that network is dark. The canary did its job. It just was not the job you needed.
PagerDuty will not stop
Your phone has been bleating for an hour. Half of it is noise, half of it is the same symptom with a different name, and you cannot tell which is a false alarm without opening three other products.
Who forgot Statuspage?
incident.io is open. The war room is loud. Customers are already posting. Somewhere between the pager and the shell, nobody updated the page - again.
Then it narrows to one device
The fleet question becomes a person question - and the stack still does not answer.
Where is it?
You have a serial, or a hostname, or a guess from a ticket. Inventory is in another tab. The map is somewhere else. The shell needs a different login again.
Who owns it, and who do I call?
Customer, site, account manager, on-call engineer - the ownership chain is not on the alert. It is in a CRM, a spreadsheet, or someone's head.
What happened yesterday?
Maintenance history, last healthy check-in, recent firmware, last remote session. Without that timeline you are debugging the present with no memory.
One designed story instead
Same device record from the fleet cohort through the phone, the shell, the incident, and the status customers see.
Remote shellsecure access
$ tail -n 50 /var/log/syslog12:05:42 alert routed to robotics@device online - 2ms latencyThe fleet condition is the alert
Among devices running right now, the whole Starlink cohort dropped. That is the page - not a lonely canary, and not a customer tweet.
The phone opens into context
Affected devices, ownership, and site path are already on the notification. You do not rebuild the outage from scratch in the next tool.
The shell, the incident, and the status stay together
Endpoint monitors beside the terminal. The war room on the same record. Statuspage language that matches what engineering already knows - because it is the same story.
Run the outage in one designed workflow.
Install the agent and see fleet monitors, phone alerts, terminals, and customer status share one device record.