I was the second SE at Datadog. For years my job was helping teams answer one question about their systems: is it working, and how do you know?
I’ve been reading a lot about robots this month, and I keep seeing the same question with a different machine attached.
Uptime is the business case
When Agility Robotics announced the fast-charging battery for its Digit 5 humanoid, its Chief Business Officer Daniel Diez said : “For our customers, Digit’s uptime is the business case.”
Swap “Digit” for the name of any SaaS product and that sentence would fit on an SRE team’s wall.
I covered the battery math in the 20-hour robot . The short version is that robots are mostly fixed cost, so every hour they aren’t working is money. That makes uptime the first metric. It isn’t the only one.
The hidden cost is people
Anthropic’s report What work can robots do? builds robot costs from the ground up. Operating costs include maintenance, part-time human supervision and energy. The report also notes that its cost estimates “often include human supervisory, exception-handling, or repair work.”
So when a robot gets stuck, someone walks over. When it drops something, someone picks it up. When it faults, someone fixes it. Every one of those is a cost, and none of them shows up on the robot’s spec sheet.
Some home robots make it obvious. In MarketWatch’s test of two household humanoids, the robots vacuumed floors and wiped counters “with some help from humans behind the scenes” , with every move streamed to teleoperators at the company’s office. That’s not a knock on them. They’re upfront about it. It’s just the clearest picture of where the cost goes.
If people are part of the cost, then how often people have to step in is the metric that matters most.
The golden signals, for a robot
In software we talk about latency, traffic, errors and saturation. Here’s how I’d translate them for a robot fleet.
| Software signal | Robot version |
|---|---|
| Availability | Hours working out of hours scheduled |
| Latency | Time per task, compared to a person doing it |
| Errors | Failed tasks, drops, falls, e-stops |
| Saturation | Time on the charger, queue of waiting work |
| Toil | Human interventions and teleoperator takeovers |
The last row is the one I’d build the whole dashboard around.
What I’d collect
Every robot should report the same metrics with the same tags: robot ID, site, model, hardware revision and software version. Without the tags you can’t answer the only question that matters during an incident, which is “what changed?”
robot.battery.state_of_charge
robot.battery.cycles_total
robot.battery.temp_c
robot.charge.minutes
robot.task.attempts
robot.task.success
robot.task.duration_s
robot.intervention.count (by reason)
robot.teleop.takeover_s
robot.fault.count (by type)
robot.fall.count
robot.estop.count
robot.motor.temp_c (by joint)
robot.mood nominal
Even hobby hardware is heading this way. Pollen Robotics’ $399 Microduck
ships with a robotctl monitor command for robot status. If a 25 cm robot duck has a status command, a humanoid working a warehouse shift should have a real telemetry pipeline.
The SLOs I’d start with
- Availability. Percent of scheduled hours the robot is working or ready. This is where the battery shows up.
- Task success rate. Per task type. A robot that’s great at totes and bad at bags should be a known fact, not a surprise.
- Mean time between interventions. How long the robot works before a person has to touch it. This is the single best number for how much hidden labor you’re paying for.
- Mean time to repair. When a robot faults, how long until it’s back. This is MTTR with a wrench.
That third one is the robot version of a metric I’ve cared about for years. In the pager post I wrote about how agents are changing who answers the page. Robots raise the same question in the physical world: when the machine gets stuck, who answers, how fast, and how often?
Don’t skip the boring part
The same lessons from running services apply, and they’re the ones people skip.
Ship telemetry before you ship the fleet. Adding metrics after the robots are on the floor is like adding monitoring after the outage.
Alert on symptoms, not every sensor. A humanoid has a lot of joints and a lot of temperature readings. If every one can page someone, nobody will read any of them. I wrote about that in revisiting observability . Signal quality is the whole game.
Tag by software version. Robots get software updates too. When a new release goes out and interventions jump, you want to see it in an hour, not at the end of the quarter.
Compare against a person. The real baseline for a robot isn’t another robot. It’s what a person does in the same hour. Anthropic built its whole cost model on that comparison, and your dashboards should too.
Where this goes
Robot companies are going to need SRE teams. Robot buyers are going to need dashboards. And somebody is going to be on call for a humanoid at 3am.
I’d rather that person have good telemetry.