Observability for hardware: what generic tools miss

What is observability, and how is it different from monitoring?

Monitoring answers a question you already knew to ask — is the CPU above 90%? You define the check ahead of time, and it tells you pass or fail.

Observability is the broader property: can you ask new questions of a running system from the outside, without shipping new code to it? When a device does something you didn’t predict, do you have enough signal to figure out why?

For software, the community settled on three pillars — metrics, logs, traces. They map cleanly onto request-driven systems. They map less cleanly onto a motor controller.

Why hardware observability is different

Generic dashboards work fine for software services. Hardware is different in a few specific ways.

• ▸Spatial context is the signal. A motor controller has twelve temperature sensors. A flat list of twelve series tells you nothing useful — it’s twelve lines on a chart. What you need to know is that three are the output stage, four the left side of the board, five the right, and the left side is running 8°C hotter than it should. Where a reading comes from is often the whole diagnosis.
• ▸The network is not reliable, and that’s normal. Devices go offline. They reconnect with a burst of buffered data. They send duplicate readings, and readings out of order. A data layer that treats a connectivity glitch as a gap makes healthy hardware look broken to whoever’s on call. This is the hard part of remote monitoring →
• ▸The clock is a problem. A board that boots offline doesn’t know what time it is. Timestamps drift. Time is something to correct, not assume.
• ▸Fleets are high-cardinality in a physical way. A hundred devices, dozens of metrics each, meaningful per-device and across the fleet. “Is this one drifting relative to its siblings” is a normal hardware question and an awkward one for tools built around service-level aggregates.

Observability tools, and where they stop for hardware

There are good observability tools here. It’s worth being honest about them.

• ▸Grafana + InfluxDB/Timescale is the default do-it-yourself stack, and it’s genuinely good — built for anyone who wants to monitor a time series, flexible, mature, huge ecosystem. What it doesn’t have is hardware-native context. A Grafana panel showing twelve temperature series is twelve lines; it won’t show you they map to two sides of a board. Spatial context, edge buffering, clock correction — you build those yourself, on top.
• ▸Memfault / Balena are strong at device management — OTA firmware, provisioning, remote access. That’s a different job from observing what the device is doing in the field. Named so we’re clear about scope: this isn’t that.

The honest summary: general-purpose observability is built for anyone monitoring anything. It fits software services out of the box, and it fits hardware after you build the hardware-specific parts yourself.

What hardware-native observability looks like

This is where Plexus sits, and the design follows directly from the differences above.

• ▸Dashboards that know the geometry. You upload the physical layout — a board outline, a CAD file, a vehicle schematic — and map metrics to positions. A thermal overlay on the actual PCB tells you which side is hot at a glance, instead of asking you to decode twelve lines.
• ▸The data layer assumes the network will fail. The device SDK buffers locally (survives restarts and power loss), retries with backoff, and corrects its clock on reconnect. A dropped WAN link is transparent, not a hole in your chart.
• ▸Alerting that’s deterministic and explainable — threshold and statistical (z-score) rules with anti-flap built in, not a black box. Why we started with the explainable version →

And the boundary, stated plainly: Plexus is about the data — observing what devices do in the field. It doesn’t do OTA updates, provisioning, or remote SSH. If you need those, pair it with a tool that does.

When not to switch

If you’re already running InfluxDB and Grafana and they’re working for you, there’s no reason to switch. The pitch here isn’t that generic tools are bad — they’re good, and they were built for a different shape of problem. The pitch is narrower: if you’re a hardware team spending real engineering time rebuilding spatial context, edge buffering, and clock correction on top of a software-first stack, that’s the gap Plexus was built to close.

Questions we get

Ship device data in one line.

Point a device at Plexus in one line of Python and watch it land, in context, on a hardware-native dashboard.