Blame Starlink (or not) before you blame your product

Polar Freight runs trailer telematics and roadside cabinets across mixed WAN - often Starlink on long corridors. Ops sees a sudden offline wave. Truck rolls and firmware bisects start before anyone asks whether the connectivity provider failed. Flat “devices offline” views hide the cohort that actually moved together.

Without Dataplicity

Hours lost blaming the product. No durable way to group devices by ISP. Link quality is a feeling, not a last-day sparkline. Polar’s support queue asks “how many trailers on this path?” and gets a spreadsheet pivot three hours late.

With Dataplicity

1. Filter by ISP cohort. Devices pick up ASN-derived property tags such as location:isp:starlink (and other location:isp:* slugs). Filter the fleet or map before you dispatch - Polar’s corridor question becomes a tag filter, not a meeting.
2. Monitor the cohort. Scope offline or ratio device monitors to those tags so “all Starlink dark” is a first-class signal, not a spreadsheet pivot.
3. Inspect link quality on the units that matter. Per-device connection quality (reachability band and latency over about the last day, on Pro+ plans) separates “cannot reach us” from “reachable but slow.”
4. Write the altitude on the incident - ISP vs product - before status updates or truck rolls. Customer-safe status can say provider degradation without opening internal diagnostics.

ISP is inferred from viewer ASN at authentication, not modem telemetry. This is cohort operations plus a short quality window - not a multi-month ISP analytics warehouse.

Outcome

Minutes to “network vs us,” not hours of false firmware hunts - and Polar holds dispatch until the altitude is clear.

Next

• Networks and tags
• Device monitors
• Create monitors and alerts
• From signal to verified recovery

Related: Illustrative customers, Field advantages, Connected product company, Monitor the cohort, not just the device