Robotics observability guideWhat is robotics observability?
What it means for robots, how it differs from monitoring, and what to look for before you pick a platform.
Short answer
Robotics observability is the ability to understand what a robot is doing, and why, from the data it produces. It combines live monitoring of metrics and robot topics with logs, traces, events and full-fidelity recordings, so an engineer can explain a failure they did not predict without being next to the robot.
Robot monitoring vs robotics observability
Robot monitoring answers questions you thought of in advance. Is the battery above 20%? Is the lidar publishing at 10 Hz? Is the CPU below 90%? You pick the signals, draw dashboards and set alarms. Every robotics team needs this, and it catches the failures you already know about.
Robotics observability is what you need for the failures you did not see coming. A robot stops in an aisle, and nothing in the dashboard crossed a threshold. To explain it you need the logs from the planner, the trace of how long each step took, how this robot compares with the rest of the fleet, and ideally the camera and lidar data from the seconds before it stopped.
The term comes from control theory, where a system is observable if you can infer its internal state from its outputs. In software it came to mean metrics, logs and traces. For robots that list is too short, because the most important output is often what the robot perceived, and that lives in sensor data.
Why observability for robots is harder than for servers
Most observability tools were built for servers in a data centre: always powered, always connected and identical by design. Robots break each of those assumptions.
The network comes and goes
Robots drive through dead zones, live on shared Wi-Fi or ride on cellular data plans. A collector that assumes a stable link will drop exactly the data you need after an incident.
Power cuts are normal
Batteries run flat, operators hit the e-stop, a robot gets unplugged. Whatever was in memory is gone, so anything worth keeping has to reach the disk safely.
The data is heavy and multimodal
Lidar, cameras, point clouds, poses and transforms arrive at high rates. Streaming all of it to the cloud is rarely affordable, yet you need it when something goes wrong.
Every robot drifts a little
Different hardware revisions, calibration, software releases and customer sites. A fault often only makes sense once you can compare one robot with the rest of the fleet.
The signals a robotics observability platform collects
Good robot observability puts these side by side on one timeline, for one robot or the whole fleet. Each one answers a different question, and the hard incidents usually need several of them.
Host metrics
CPU, memory, disk, temperature and network on the robot computer. The first place resource starvation shows up.
Robot topics
On ROS 2 robots, the topics themselves: rates, latencies and the values inside the messages, such as battery state, velocity or localisation confidence.
Logs and traces
Application logs and OpenTelemetry traces show what the software decided and how long each step took, on ROS 2 or any other stack.
Recordings
Full-fidelity sensor data from the minutes around an incident, usually as MCAP, so you can replay what the robot actually perceived.
Events and incidents
Alarms, state changes and operator actions with start and end times, so you can count incidents and measure how long they lasted.
Context
Which robot, site, hardware revision and software release. Without it you cannot tell a one-off from a pattern.
Robotics observability across the robot lifecycle
Teams often add observability after the first painful field incident. It pays off earlier: the same agent and the same dashboards work on a simulator, a test bench and a production robot, so the baseline you build in QA is the one you compare against in the field.
Simulation and QA
Record every test run and turn expectations into alarms, so a regression shows up as a failed check with the data attached.
Field trials
Watch pilot units at a customer site you cannot visit every day and sign off on measured behaviour.
Production fleets
Live dashboards and alarms for every robot, with the recording from the moment it failed.
Support and operations
Start each ticket with the robot's history and recording instead of a phone call and an SSH session.
What to look for in a robot observability platform
Feature lists look alike. These are the properties that decide whether a platform still works once robots leave the lab.
Integration without code changes
On ROS 2 the agent should find your topics by itself. Other software should be able to report through OpenTelemetry instead of a proprietary SDK.
Built for bad networks
Telemetry should be compressed, buffered on the robot while offline and delivered when the link returns.
Recording on the robot that survives power loss
A rolling buffer of full-fidelity data on the device, so you can pull the minutes around an incident after the fact.
Open formats
MCAP for recordings and OpenTelemetry for metrics, logs and traces, so your data opens in other tools and stays yours.
Fleet-scale setup
Templates and enrollment keys so a new robot configures itself on first boot instead of by hand.
Alarms that carry evidence
Notifications in the channels your team already uses, linked to the telemetry and recording behind them.
Runs where your robots run
Light enough for the robot computer, packaged for your OS, and available hosted or inside your own infrastructure.
We measured how our own agent handles power cuts, weak links and outages against ros2 bag record. The method and results are on the benchmarks page.
Where Grafana, Foxglove and rosbag fit
Most robotics teams already use several of these. They are good at their own job, and a robotics observability platform should work with them rather than replace them.
| Category | Good at | Gap for robot fleets |
|---|---|---|
| IT monitoringGrafana, Prometheus, Datadog | Servers, containers and cloud infrastructure | No notion of robot topics, sensor data or recordings, and they expect a stable connection |
| VisualizationFoxglove, Rerun, PlotJuggler | Exploring a recording once you have it | Somebody still has to notice the problem and get the data off the robot |
| Recordingros2 bag record | Capturing topics on a single robot | No live view, no alarms and no fleet, and the last part of a recording is lost on a power cut |
| Fleet managementVendor fleet managers | Task assignment, traffic and charging | Built to run the operation, so they rarely help an engineer explain a failure |
A detailed comparison with Grafana, Foxglove, Rerun and PlotJuggler is on Why Insaion.
Getting started with robotics observability in Insaion
Insaion is a robotics observability and monitoring platform. It is ROS 2 native and open to the rest of your stack through OpenTelemetry. Most teams have their first robot reporting in a few minutes.
- 1
Install the agent
As a Debian package with a systemd service, or as a Docker container, on the robot computer, a simulator host or a test rig.
- 2
Let it discover your data
On ROS 2 the agent finds topics on its own. Turn on OpenTelemetry ingestion for services written in any language.
- 3
Apply a template
Dashboards, recording rules and alarms defined once and applied to every new robot that joins the fleet.
- 4
Write alarms for what matters
Thresholds on any metric or topic value, routed to email, Slack, Microsoft Teams or Telegram.
- 5
Pull the recording when something breaks
Upload the minutes around the alarm from the robot's rolling buffer and replay them in the browser or in your own MCAP tools.
Feature details are on the platform page.
Robotics observability FAQ
What is the difference between robot monitoring and robotics observability?
Robot monitoring watches signals you chose in advance and alerts when one crosses a threshold. Robotics observability adds the context to explain problems you did not anticipate: logs, traces, fleet-wide comparison and the full-fidelity recording of what the robot sensed. Monitoring tells you a robot stopped. Observability lets you work out why.
Is robotics observability only for ROS 2 robots?
No. ROS 2 is the most common robotics middleware, and a good platform reads ROS 2 topics without code changes. Software outside ROS 2 can report metrics, logs and traces through OpenTelemetry, which has SDKs for C++, Python, Rust, Go, Java and more.
Can I use Grafana or Datadog for robot observability?
They work well for infrastructure, and some teams export robot metrics into them. They do not understand ROS 2 topics or MCAP recordings, and they assume an always-on connection, so you end up building the robot-specific parts yourself.
What format should robot recordings use?
MCAP is the open standard for robotics recordings and the default storage format for ROS 2 bags since Iron. It opens in Foxglove, Lichtblick, Rerun and PlotJuggler, so recordings stay portable between tools.
How do you observe robots on weak or intermittent networks?
Collect and buffer on the robot. Send compressed telemetry when the link allows, keep full-fidelity data in a rolling buffer on the device, and upload only the recordings you ask for. Insaion publishes measurements of this on its benchmarks page.
See the benchmarksDo I need to change my robot code to add observability?
Not with Insaion. The agent discovers ROS 2 topics on its own and reads host metrics directly. Code changes are only needed if you want to add your own OpenTelemetry traces or metrics.
See your first robot in minutes
Free plan with unlimited devices. No credit card required.