How reliable are warehouse AMRs really?
2026-07-24
Last verified July 24, 2026. This is independent analysis of publicly available data — it names no confidential deployment and takes no vendor's number on trust. Figures attributed to vendors or trade press are marked as such.
The short answer
Direct answer: You largely can't verify it — not from public data. No independent benchmark for warehouse-AMR reliability exists. The uptime figures vendors publish, often 99% or higher, are measured by methods each vendor defines and rarely discloses, and none are comparable across vendors. Below is how to read the numbers you are given, what actually drives downtime, and why reliability quietly sets resale value.
~13%Share of warehouses projected to run at least one fulfillment AMR by 2030 (Interact Analysis) — the installed base is early, so multi-year failure data barely exists yetSource: Interact Analysis, via trade press 2025Is there an independent reliability benchmark for warehouse AMRs?
No. Across IEEE, arXiv, Google Scholar, and the major analysts, no independent, long-term, warehouse-AMR-specific reliability or uptime study surfaces. The analysts who cover this market — Interact Analysis, MHI — publish adoption and market-size forecasts, not reliability measurements.
The one genuine piece of independent mobile-robot field data is two decades old and about a different machine: the Carlson and Murphy field studies (2004–2005) recorded a mean time between failures of roughly 8 hours in the first study and about 24 hours in the follow-up — with system availability under 55%, and the control system the single most common failure source (about a third of failures). They were studying search-and-rescue and field robots, not warehouse AMRs. It is cited here to show what real independent failure data looks like, and how little of it exists for logistics robots.
The person best positioned to have a number — Aaron Prather, director of robotics standards at ASTM International and a 27-year FedEx veteran — frames the stakes without offering a dataset, because none exists to offer:
"Reliability, in this mature landscape, is not a feature. It is the product."
— Aaron Prather, Six Degrees of Robotics, December 2025
That absence is the honest main point. Everything a buyer is shown comes from the vendor selling the robot.
Why do vendors' uptime numbers look so good?
Because the vendor defines the measurement, and there is no standard forcing them to define it the same way. The mobile-robot standards that exist are safety and terminology standards — ANSI/RIA R15.08 and ISO 3691-4 govern safety, and ISO 8373 defines robotics vocabulary. None specifies how to measure uptime or availability. So "99.9% uptime" from two vendors can describe two different quantities.
The clearest way to see this is the one vendor transparent enough to publish its formula. AutoStore reports 99.7% uptime and an MTBF above 3,000 hours across a fleet of hundreds of systems — and it publishes the calculation. Reading it is the lesson: its uptime formula carries the footnote that it "does not include manual system stops and super-user response time," and its MTBF counts only "system failures caused by the Robots," excluding non-robot faults. The number is not wrong. It simply measures the robot at its best and leaves out much of what an operator actually experiences.
That is the general pattern. A headline reliability figure usually answers a narrower question than the one a buyer is asking:
| Metric | What the vendor usually means | What it can leave out |
|---|---|---|
| MTBF (mean time between failures) | Average operating hours between hardware faults of the robot itself | Battery swaps, charging, traffic jams, localization recovery, human rescues, software restarts |
| Uptime / availability % | Share of scheduled time the system was "running" | Whatever the vendor's formula excludes from "down" — often manual stops and the minutes before a human responds |
| MTTF (mean time to failure) | Average life of a non-repairable part before replacement | A different quantity from MTBF, and often conflated with it |
| MTTR (mean time to repair) | Average time to restore after a fault | How often faults happen — a fast repair on a frequent fault still means low availability |
The operator-relevant number is availability — MTBF divided by (MTBF + MTTR) — and it moves with how the vendor counts a "failure." Cross-vendor comparison of published headline numbers, without the formulas underneath, is close to meaningless.
What actually takes an AMR offline?
The failure modes are well understood even where the frequencies are not. In production, AMR downtime comes from battery charging and swaps (charging-equipment vendors cite robots sitting idle 15–20% of the day, a figure to treat as directional since the source sells the fix); localization drift — the robot losing track of where it is — that sends a unit into a recovery stop; traffic deadlock and congestion, which get much worse, faster than the robot count grows, as fleet density rises; blocked paths that need a human to walk over and rescue the unit; network dropouts, since a Wi-Fi gap can pause a robot mid-task; sensor contamination on lidar and cameras; and ordinary mechanical wear on wheels, casters, and lift mechanisms.
Two honest caveats matter here. First, almost every published frequency or percentage comes from a company selling the remedy — a battery maker, a charging-infrastructure firm, a predictive-maintenance platform — so the numbers carry selection bias and belong in the "directional" column, not the "audited" one. Second, and more useful: because congestion and contention scale with density, a per-robot specification does not predict fleet behavior. Reliability is a property of your layout, duty cycle (how continuously the fleet runs), and fleet size — which is exactly why a vendor's number from another site does not transfer to yours.
Why does reliability set resale value?
Because a robot you cannot service, or cannot resell, is worth what a stranded asset — one that cannot be sold or redeployed — is worth. Two features of this market make reliability and residual value the same question.
First, serviceability dies with the vendor. When Shopify sold 6 River Systems to Ocado in 2023 for $12.7M — against the $450M it paid in 2019, a roughly 97% collapse — the write-down reflected a strategic exit, but the mechanism it exposes is real: an AMR fleet is not a liquid asset. Zebra is shutting down the Fetch Robotics AMR line it bought for $290M in 2021, keeping only a minimal support team to manage existing deployments; those operators' robots became serviceability orphans once the vendor withdrew support. Spare parts, firmware, and remote support all depend on a living vendor.
Second, there is nowhere to reprice. Used industrial robot arms trade on established secondary markets — SurplusRecord lists ABB, FANUC, and KUKA arms from a few thousand dollars to over $99,000, and BTM Industrial put more than 150 used FANUC, ABB, KUKA, and Yaskawa robots to auction in a single Ohio liquidation in May 2026. The venues for reselling used AMRs, by contrast, are new and thin — a general robotics marketplace like Robotbids only opened in 2025, listing AMRs alongside arms and humanoids rather than in a deep, AMR-specific market. There is nothing yet comparable to the mature auction infrastructure that exists for industrial arms. And under Robots-as-a-Service (RaaS) the vendor typically retains title and the fleet software, so the operator has nothing to sell even if a buyer existed. Reliability data would be the input to a residual-value curve — how much a fleet is worth as it ages — and it is precisely the data no independent party holds.
$450M → $12.7MWhat Shopify paid for 6 River Systems (2019) versus what it sold for to Ocado (2023) — and the used-AMR resale market is still too thin and new to reprice a fleet againstSource: The Robot Report; Ocado 2023 filingsWhat should a buyer actually check?
- Ask for the formula, not the number. What does the vendor's uptime figure count as "down"? Do manual stops, human response time, charging, and non-robot faults land inside or outside it? A number without its definition is not comparable to anything.
- Contract on availability, measured your way. Put a defined availability target, a stated measurement method, and service credits into the RaaS SLA — rather than accepting a marketing uptime percentage.
- Secure telemetry access and portability. Under RaaS the vendor holds the fleet's failure data. Negotiate your right to see it and export it; it is the only record of how your fleet actually performs.
- Separate the spec from the fleet. A per-robot MTBF says little about behavior at density. Ask what happens to throughput and stoppages as the fleet scales in your specific layout.
- Underwrite the vendor, not just the robot. Parts, firmware, and support depend on the vendor surviving. A robot from a discontinued line is a reliability and residual-value liability regardless of its spec sheet.
FAQ
Is there an independent reliability benchmark for warehouse AMRs? No. As of 2026 there is no independent, long-term, warehouse-AMR reliability study in the public or academic record. The uptime figures in circulation are vendor-published, measured by methods each vendor defines, and are not comparable across vendors. The only genuine independent field-failure data on mobile robots (Carlson and Murphy) studied search-and-rescue robots two decades ago, not warehouse AMRs.
What is a good uptime number for a warehouse AMR? There is no standard that defines how AMR uptime is measured, so a '99.9% uptime' from one vendor and the same figure from another are not the same quantity. What matters is the formula behind it: does it count manual stops, the time a human takes to respond, charging, and non-robot faults, or exclude them? Ask for the definition before you compare two numbers.
Can I trust a vendor's MTBF number? An MTBF (mean time between failures) figure is usually a design or bench estimate for the robot's hardware. What you experience as availability also includes battery swaps, traffic jams, localization recovery, and human rescues — none of which hardware MTBF captures. Availability equals MTBF divided by (MTBF plus mean time to repair); ask which quantity the vendor is quoting.
What actually causes AMR downtime? In practice: battery charging and swaps, localization and mapping drift, traffic deadlock and congestion at scale, blocked paths that need a human rescue, network dropouts, sensor contamination, and mechanical wear. Most published frequency figures come from vendors selling a fix — batteries, charging, predictive maintenance — so treat them as directional, not audited.
What happens to my robots if the vendor goes out of business? They can become serviceability orphans — no spare parts, frozen software, no support — and under Robots-as-a-Service the vendor often owns the fleet software and the title. Shopify paid $450M for 6 River Systems in 2019 and sold it for $12.7M in 2023; Zebra is shutting down its Fetch AMR line. Vendor viability is a reliability and residual-value question, not only a commercial one.
Sources
Independent field data: Carlson & Murphy, "Reliability analysis of mobile robots" (IEEE ICRA, 2004) and the underlying USF thesis (2005). Standards: ANSI/RIA R15.08 and ISO 3691-4 (safety); ISO 8373 (robotics vocabulary) — none defines reliability/uptime measurement. Vendor disclosure: AutoStore MTBF & Uptime Report and its uptime/availability definitions. Independent voice: Aaron Prather, Six Degrees of Robotics. Market scale: IFR World Robotics 2025 — service robots; Interact Analysis warehouse-automation forecasts (via trade press). Vendor viability: The Robot Report — Shopify's loss on 6 River Systems; The Robot Report — Zebra winding down Fetch. Secondary market: SurplusRecord used-robot listings (arms); BTM Industrial May 2026 robot auction; Robotbids (used-robot marketplace, launched 2025). Downtime and TCO figures are drawn from vendor and practitioner sources and are marked directional in the text.
Get Rovara intelligence
Independent reliability, residual-value, and deployment-risk intelligence on the robot fleet economy. No spam, no supplier placement.
(Wire-up pending: set NEXT_PUBLIC_BEEHIIV_URL.)