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 #

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

Blame Starlink (or not) before you blame your product #

Without Dataplicity #

With Dataplicity #

Outcome #

Next #