Appearance
Separate one bad unit from the network died #
A Harbor store goes dark. A Polar Freight trailer stops checking in. Support’s first fork is simple and expensive if wrong: one bad unit, or the network (often Starlink or another ISP) died under a whole cohort?
This story is the connected-product framing of the same decision as Blame Starlink (or not) before you blame your product.
Without Dataplicity #
Every ticket looks local. Firmware bisects and truck rolls start while the corridor is dark. Customers hear “we are investigating your device” during a provider outage.
With Dataplicity #
- Open the reported unit with customer and site context - confirm identity before acting.
- Widen to the cohort - same class, site, or
location:isp:*tag - before treating the case as unique. - Compare monitors and connection quality on the population that moved together.
- Write the altitude on the incident (one unit vs network vs product) and only then choose remote fix, dispatch, or provider escalation.
Outcome #
Support spends minutes classifying the fault class - not hours repairing the wrong layer.
Next #
- Blame Starlink (or not) before you blame your product
- Monitor the cohort, not just the device
- Decide dispatch vs remote fix on a field support call
Related: Illustrative customers, Connected product company, Field advantages