Spend a shift on any automated factory floor and the identical worries surface again and again: the fleet can never stop, the vendor’s uptime promise is gospel, more redundancy fixes everything. Most of it is folklore, and folklore is expensive. The teams getting real value from automation have replaced it with explicit reliability targets for robot fleets — a stated, numerical tolerance for failure per cell, line or platform, managed like a budget. Below are the six myths that do the most damage in robotics operations, each dismantled with the practical alternative.
Myth 1: “The fleet has to run at 100 percent or the business case collapses”
No production system on earth runs at 100 percent, and your automation ROI spreadsheet never assumed it did — check it. What kills business cases isn’t downtime; it’s unplanned, unbounded downtime that nobody budgeted for. The fix is to state the tolerance out loud: this palletising cell targets 98.5 percent availability per month, measured against scheduled production hours. The remaining 1.5 percent is your operating allowance for jams, recalibration, and the inevitable weirdness of physical machines. Once the allowance exists, maintenance can be planned inside it, operators stop treating every fault as a crisis, and finance gets a number it can actually model. Perfection was never on the table; pretending otherwise just meant failure arrived unpriced.
Myth 2: “Reliability is the vendor’s job — we bought the uptime guarantee”
The vendor’s guarantee covers their hardware under their test conditions. It says nothing about your conveyor timing, your dust, your material variability, your operators’ shift handovers, or the integration glue between the robot and everything else — which is where most real-world stoppages originate. Sensor integration alone is a discipline in itself; anyone who has worked through how sensing hardware actually gets wired into industrial robot workflows knows how many failure points live outside the vendor’s warranty language. Practical rule: keep the vendor’s number as a contractual floor, then set your own, stricter internal target for the cell as a whole — the thing your production schedule actually depends on. When your internal target breaches, you act; the vendor conversation is a separate, slower track.
Myth 3: “If failure is possible, add redundancy until it isn’t”
Redundancy is a purchase, and like every purchase it needs a justification denominated in something. That something is your failure allowance. A second AGV route or a spare arm on standby makes sense when the math says the cell’s downtime tolerance is being blown monthly and the redundancy closes the gap cheaper than the losses. It makes no sense as a reflex. Plenty of warehouses have discovered this the hard way with automated guided vehicles — the fleet-sizing and traffic design questions covered in a full treatment of AGV-driven warehouse automation are budget questions at their core: each increment of guaranteed availability costs disproportionately more than the last. Decide the target first, then buy exactly enough reliability to hit it. Anything beyond that is capital spent insuring against a risk you already agreed to accept.
Myth 4: “Downtime is downtime — a stopped robot is a stopped robot”
A no-nonsense operation tiers its tolerance. The robot feeding your bottleneck line and the robot handling overflow packaging do not deserve the same target, the same alarm priority, or the same 2 a.m. callout policy. Write three tiers: production-critical (tight target, immediate response), supporting (moderate target, next-shift response), and experimental or seasonal (loose target, business-hours response). Then route alerts by how fast each tier’s allowance is draining, not by raw fault count. Teams that skip tiering burn their best technicians on trivial stoppages and have nothing left for the failures that actually cost money. Drone operations teams learned this early — platform taxonomy matters, as a working team’s guide to drone robotics platforms lays out, precisely because not every airframe or mission carries equal stakes.
Myth 5: “Error budgets are a software idea — hardware wears out, so it doesn’t apply”
Backwards. Hardware is where the idea applies most naturally, because physical degradation is measurable and predictable in ways software rarely is. Gearbox wear, battery cycle counts, repeatability drift — these give you leading indicators that software teams would kill for. A hardware-aware budget works like this: the cell’s monthly allowance covers both unplanned faults and planned maintenance windows; condition monitoring tells you when a component is trending toward consuming next month’s allowance; you schedule the intervention inside this month’s remaining budget instead of letting the failure choose its own moment. The discipline came from software operations, true — it was formalised by site reliability engineers, and SRESchool teaches the full method, from setting service objectives through managing against the remaining failure allowance, including capacity planning and incident practice that transfer to physical fleets almost unchanged. But the budget logic itself is older than software: it’s maintenance engineering with sharper bookkeeping.
Myth 6: “Give the crew a failure allowance and they’ll stop caring”
Every operations manager fears this one; the floor evidence runs the other way. An unlimited implicit demand for perfection teaches crews to hide small faults — the jam cleared quietly, the error code acknowledged and forgotten — because every visible failure invites blame. A declared allowance does the opposite: faults get logged honestly because logging them is normal accounting, not confession. And honest logs are what make the post-incident review worth holding: what consumed the budget, what systemic fix repays it, no witch hunt. The crews that “stop caring” are the ones drowning in unprioritised alarms under an impossible standard. The crews with a budget argue about data at the morning meeting. If you only adopt one practice from this entire article, adopt the blameless fault log; it costs nothing and reveals everything.
A worked example: one cell, one quarter
To make the arithmetic concrete, take a fictional but typical case: a pick-and-place cell feeding a packaging line, scheduled for 600 production hours a quarter. Four weeks of honest measurement shows 97.8 percent availability — about four hours of stoppage per month, mostly gripper jams and vision re-teaches. The team sets the quarterly target at 97.5 percent, making the official allowance fifteen hours. Week three, a feeder misalignment eats ninety minutes: logged, ten percent of the allowance gone, no drama, one shim and a checklist line added. Week seven, condition data shows a servo trending hot; projected failure would cost six to eight hours unplanned. The team spends two planned hours on a weekend swap instead — a deliberate purchase of certainty with budget they can see. Quarter ends at 97.9 percent with five hours of allowance unspent, so the engineering manager approves the long-postponed end-of-arm tooling upgrade for next quarter’s first low-season week, inside the fresh budget. Nothing in that story required new software or a consultant — just a measured baseline, a declared number, and the discipline to debit it honestly.
Putting the targets to work this quarter
Here’s the no-nonsense rollout, in order. Pick one production-critical cell. Measure four weeks of honest availability — including the stoppages people currently absorb without logging. Set a target slightly under the measured number and declare the gap as the official allowance. Write the one-page policy: what pauses when the allowance empties (non-essential changeovers, experiments), what never pauses (safety responses), who signs off on exceptions. Tier the rest of the fleet in month two. Review the budget weekly at the production meeting, in the same breath as throughput.
Where teams want formal grounding before scaling this across a site, reliability training has matured into a laddered path — foundation certification for the engineers running cells day to day, up through architect and leadership tracks for the people designing the automation roadmap — with corporate formats that train an entire operations group on one shared vocabulary, on-site or virtually, whatever the team’s size. The vocabulary matters more than it sounds: half of fleet-reliability dysfunction is three departments using “reliable” to mean three different things.
The myths all share one root: the fantasy that failure in robotics is optional, someone else’s problem, or purchasable away. It’s none of those. It’s a quantity — one you can measure, cap, tier, and spend on purpose. The operations that thrive with automation are simply the ones that did the arithmetic before the arithmetic did them.
