Worked scenarios for investigating device drift, rollout faults and support requests. Follow the available evidence to a decision, then check the result on your own fleet.
A prototype, a first batch or an established fleet. Start where the work is.
Prove remote access on a development device, or investigate a fault with Device Check.
Start with one device →Make installation and device identity repeatable before the first batch goes out.
Prepare the first batch →Use your existing installation or update process to connect a reachable cohort. Keep your customer application.
Operate an existing fleet →Gold configs and desired-state manifests assume managed servers. IoT fleets need bounded capture and peer-learned normal instead.
Device Check · in the app
From a device record, run about fifteen to twenty minutes of health, network path, clock skew, and process evidence - then analyse that window.
See remote diagnosticsIn-app Device Check is attached to a device. Separate from free public Device Check (no account). Open public Device Check
Analysing this capture - not a continuous feed
Device Class Pulse
Pulse learns class normal from peers as they run, then flags units that stop looking like the rest. No golden image required.
See Pulse on the product tourConnectivity
Alert on a carrier cohort, then tell regional coverage apart from a suspended account or an expired card.
Open playbook
Product quality
Correlate repeated syslog signatures with firmware version, device class, and rollout group.
Open playbook
Customer trust
Turn device evidence into incident response, customer-facing status, and warranty context.
Open playbook
Generic monitoring understands servers. Dataplicity understands shipped devices.
Add your work email and we hand you the install command for the first device.
