Skip to content

Warehouse Automation

Warehouse Automation KPIs: What to Measure Once the Robots Are Running

Oct 20, 2026 · 14 min read · Robotech Pros

A deployed fleet produces a great deal of data and surprisingly little information. These are the metrics that tell you whether the robots are healthy, doing the right work, and paying for themselves.

Warehouse Automation KPIs: What to Measure Once the Robots Are Running

Getting robots installed and getting them to earn their keep are two different projects, and they need two different sets of numbers. Deployment reporting answers whether the system went in. Operating reporting has to answer something harder, which is whether the warehouse is measurably better off than it was.

Why fleet reporting often measures the wrong thing

Most reports from a live deployment describe robot activity. Hours powered on, missions completed, distance traveled. Those figures confirm the fleet is running. They are also easy to report well while the warehouse underneath them gets no faster.

The satisfaction data suggests the gap is common. A DHL Supply Chain survey published in November 2025 found 44 percent of organizations had deployed warehouse robotics, but only 34 percent of VP and director level executives described themselves as fully satisfied. The 2026 Intralogistics Robotics Survey points the same way: 74 percent said robotics met their business goals, 21 percent said it fell short, and 11 percent missed targets specifically on return on investment, reliability, and integration cost.

Neither survey resolves what those respondents were measuring, and that is the point. A fleet can look healthy on every number operations reports and still fail the test finance applied when it approved the capital. A reporting set that survives that review answers three questions in order. Is the fleet healthy. Is it doing the right work. Is it paying for itself.

Table 1: The metric set at a glance

QuestionMetricWhat it tells youData source
Is the fleet healthy?AvailabilityScheduled time a robot could accept workFleet state log, mode and error fields
Mean time between interventionsHow often a person has to touch the fleetIntervention records vs. error log
Charge cycles consumedHow fast battery life is being spentCharging events per robot
Is it doing the right work?UtilizationAvailable time spent on assigned missionsFleet manager mission records
Moves per robot hourProductivity, what utilization is mistaken forMissions completed per available robot hour
Empty travel shareDistance covered without a loadMission records plus load state
Mission success rateShare finished without human helpMission outcome codes
Is it paying?Cost per moveOperating cost per completed moveFinance records against fleet records
Labor hours releasedHours removed from the process replacedTimekeeping, by function not headcount
Effect on order cycle timeWhether service metrics actually movedWarehouse management system

Most reporting packs cover the first group well and the third group not at all.

The data your fleet already produces

Underreporting is rarely a data problem. A fleet speaking the VDA 5050 interface publishes a state message carrying its operating mode, whether it is driving or paused, its position and whether that position can be trusted, battery state, active errors, safety status, and the loads it carries. Version 3.0, released by the VDA in March 2026, added an INTERVENED operating mode and introduced CRITICAL and URGENT error levels, so the standard now treats a human intervention as a distinct condition rather than a kind of fault.

What is usually missing is the step that turns that stream into a metric, which means giving every count a denominator and a time window. Three hundred and twelve interventions is not a metric. Three hundred and twelve interventions across 4,100 robot hours is.

The second missing step is connecting those numbers to the ones the warehouse already reports. The Warehousing Education and Research Council benchmarks 36 operational metrics across five balanced sets, and manufacturing has an equivalent vocabulary in ISO 22400-2. Robot metrics work best feeding those sets rather than living on a dashboard nobody outside operations reads.

Question one. Is the fleet healthy?

Availability is the share of scheduled operating time during which a robot could accept work. It is the first number most fleet management software reports and the easiest to misread, because it describes the robot and says nothing about the operation. A fleet parked in a charging bay with no faults is fully available and completely useless.

Mean time between interventions is the more honest reliability measure, and usually the one that predicts cost. An intervention is any event where a person walks to a robot and does something: clears a blocked path, reseats a load, restarts a stalled mission, recovers a machine that lost localization. Each one consumes a human for several minutes, and those minutes come out of the labor saving the project was justified on. Count interventions separately from faults, and break the total down by location and cause, because they cluster. One dock door or one badly marked aisle will generate a disproportionate share, and a fleet-wide average conceals that completely. The breakdown is what a maintenance program can act on.

Charge cycles are the slowest-moving health metric and the one most often left out. Published specifications for both tote class and pallet class mobile robots put battery service life at roughly 3,000 full cycles before capacity drops below 80 percent. At three cycles a day across a 250 day operating year that is a four year horizon; at five cycles across 300 days it is two. Counting cycles per robot per day tells you which budget year the replacement lands in, and it follows directly from the charging strategy the fleet runs on.

Question two. Is the fleet doing the right work?

Utilization is the share of available time a robot spends executing assigned missions. It is the metric most often reported with pride and misunderstood in the process, because it is not a measure where higher is automatically better.

Research on fleet sizing using closed queueing networks found that adding vehicles can increase waiting times and lengthen cycle times, and that queue response climbed sharply once bottleneck utilization passed roughly 88 percent. A fleet reported at 95 percent utilization is therefore more likely congested than efficient. The robots are busy, but a growing share of that time is spent waiting for a corridor, a lift, or a drop point.

So utilization needs a partner metric. Moves per robot hour measures what utilization is assumed to measure, and the two separate under exactly the conditions that matter. When utilization rises while moves per robot hour falls, the fleet is congested rather than productive, and the fix is a traffic or layout change rather than more robots. That is also why an honest fleet sizing model derates before it divides, and it is the first thing to break when scaling a fleet past the first handful of robots.

Empty travel share rarely makes the pack and should. Mobile robots convert travel into throughput, so distance covered without a load is the clearest proxy for work the fleet does on its own behalf, and it responds to slotting rather than hardware. Measure mission success alongside it as the share finishing without human help, since almost everything finishes once somebody intervenes.

Table 2: Four metrics that are routinely confused

MetricWhat it measuresWhat it does not tell youFailure mode
AvailabilityScheduled time the robot could accept workWhether any work was actually assignedHigh availability on an idle fleet reads as success
UtilizationShare of available time spent executing missionsWhether missions were productive, or the fleet congestedPast roughly 88 percent, queueing inflates cycle time
Moves per robot hourCompleted moves per available robot hourWhether each move needed to happenFalls as the fleet grows even while robots stay busy
Mission success rateShare of missions finished without human helpWhere in the building failures clusterA fleet-wide average hides one bad aisle or dock

Availability and utilization are often reported as interchangeable. They move independently, and so do the decisions they drive.

Question three. Is the fleet paying for itself?

The third set is the one most often missing, and the only one the people who approved the capital asked for. The 2026 Intralogistics Robotics Survey found respondents ranked return on investment first among evaluation criteria at 63 percent, payback time second at 52 percent, and total cost of ownership third at 47 percent. Those are the criteria a project is approved against, so they are the criteria it should be reported against.

Cost per move is the workhorse. Take the fully loaded operating cost of the fleet, including maintenance, software, energy, and the labor hours interventions consume, and divide by completed moves. Its value comes from comparison, so calculate the pre-automation cost of the same move on the same basis and keep both side by side. That comparison is also the backbone of any honest automation ROI case.

Labor hours released is the figure most often overstated. Measure hours removed from the specific process the robots took over, by function rather than headcount, and track where those hours went. Hours redeployed to another constrained process are a real gain. Hours absorbed into the intervention queue are not, and that distinction is invisible in a headcount number.

Then check whether the warehouse service metrics moved at all. If order cycle time, on-time shipping, and lines picked and shipped per hour look the same as before go-live, the fleet is producing robot statistics rather than operational results. That check requires the fleet to be properly integrated with the WMS, since otherwise no service change can be attributed to the robots.

Setting targets when there is no public benchmark

There is no credible published benchmark for mobile robot availability, utilization, or intervention rate, and we will not invent one. Figures circulating in vendor material come from single deployments with undisclosed definitions, and the same is true of automation payback periods, which surveys rank as a top evaluation criterion without publishing a figure for it.

That matters less than it sounds, because the useful target was never the industry average. Establish your own baseline once commissioning faults are worked out, usually between weeks five and twelve, then set targets as movement against it. A fleet improving against its own week twelve numbers is demonstrably getting better. A fleet matching a benchmark of unknown provenance has demonstrated nothing. Revisit the definitions themselves each quarter, since they drift quietly when a fleet manager is upgraded or a second robot type joins.

Table 3: Setting a first target without an industry benchmark

MetricHow to set the first targetWhat should trigger a review
AvailabilityMedian of weeks 5 to 12, once commissioning faults clearTwo consecutive weeks below the baseline median
Mean time between interventionsYour own week 12 figure, plus a quarterly improvement goalAny sustained downward trend across a month
UtilizationThe level at which measured cycle time begins to rise, not a fixed percentageCycle time rising at the same time as utilization
Cost per moveThe pre-automation cost of the same move, on the same basisAny quarter in which it exceeds the manual baseline
Empty travel shareFirst full month of steady-state operationAn increase following any slotting or layout change

Every target comes from the operation's own data, which makes each one defensible without an outside figure.

What this means for your reporting pack

One page for the executive audience covering the third question: cost per move, labor hours released and where they went, and movement in the warehouse service metrics. Underneath it, an operations view carrying availability, utilization against moves per robot hour, mission success by location, and interventions by cause. Monthly for the first, weekly for the second.

If you are standing up reporting on a live fleet, or planning a proof-of-concept program and deciding what it needs to prove, Robotech Pros can help define the measurement set before the robots arrive. That is easier than reconstructing it afterward from logs never designed to answer the question.