The real product
Dataplicity
Software for IoT product companies: remote access, fleet monitoring, incidents, and fixes after devices leave the factory, without VPN or inbound ports on every site.
Worked example
Screenshots from a SiloSentry demo org on Dataplicity: devices, ops dashboards, incidents, fleet fixes. Use them to picture your own company in that seat.
Two names on this page. Here’s who they are.
The real product
Software for IoT product companies: remote access, fleet monitoring, incidents, and fixes after devices leave the factory, without VPN or inbound ports on every site.
The made-up company
Not real. A grain-bin sensor OEM we invented so the product isn’t abstract. Their customer cloud is separate. Dataplicity is how they support the gateways.
This whole site is that fiction, used as a tour.
Why this isn’t tool salad
Those products each do a job. An IoT OEM needs those jobs attached to the same device records, from install through monitoring, paging, fixes, warranty, and RMA.
A wallboard here, an on-call pager there, remote shells somewhere else, RMA in another system. Every incident starts with “which box was that?”
The device is the unit of work. Dashboards, incidents, terminals, and fleet jobs all point at the same fleet, including commercial lifecycle (licences, warranty, RMA).
1 · After devices ship
This is the foundation. Everything else (dashboards, pages, jobs) hangs off these records.
What you’d see
Gateways named for bins and sites. Classes for SKUs (Probe GW, Site Gateway). This list is what SiloSentry’s support team opens when a co-op calls.
When one box needs a human
You’re not jumping to a separate VPN tool. The shell is on the device page, next to the same identity dashboards and incidents will refer to.
2 · Running the company
This is the “what would my company look like?” part: not a feature dump, the shapes SiloSentry would actually use day to day.
Ops center
Not a generic KPI collage. SiloSentry’s “Plains elevators” display is built from their Dataplicity fleet: check-ins, heartbeats, and open incidents.
Fleet monitors
“Any Probe GW offline,” “too many Site Gateways dark,” rules SiloSentry would keep on the same devices that show up in the list and on the wall.
Incidents
A tower’s probe service down. Customer-cloud latency. Ack, own, escalate, publish, with the device or endpoint named on the incident.
On-call
Escalation paths and mobile alerts live beside those incidents, not a separate vendor login your team forgets the password to.
Fleet progression
Device Class Pulse watches whether gateways still look like their peers over time (a missing service, climbing disk, and so on), so ops sees change, not just up/down.
Fixes at scale
Harvest readiness checks, restarts, cleanups, run as fleet jobs with per-device results. The same place that paged you also runs the remediation.
3 · A day in the seat
Operations overview, the ops wall, Pulse on the Probe GW class.
Acknowledge the Tower 2 incident. Run a fleet job. Check per-device results.
Terminal or Wormhole on the one box that didn’t clear. Alerts for anything still quiet.
Customers, licences, warranty, and RMA stay in the same product. Hardware support didn’t end at install day.
Takeaway
Replace grain bins with your hardware. The shape stays: devices you can reach, ops you can see, incidents you can page, fixes you can run, lifecycle you can keep, all in one place.
Dataplicity = post-ship device ops. SiloSentry = the example setting. Your product = the real story.
Next step: dataplicity.com