At two in the morning, a warehouse supervisor watches a fleet of transport robots slow to a crawl. Nothing is broken exactly; orders are still moving, just later than anyone would like. She asks the question every operations team eventually asks: how do we decide when “slow” becomes “unacceptable”, and who decides what to do? Software teams answer with site reliability engineering, usually called SRE. This FAQ follows her questions, translating the discipline into the world of robot fleets, borrowing its definitions and figures from the SRE page in the Ops Atlas.

What does SRE mean for a robotics floor?

It means handling day-to-day operations as an engineering problem. Decide what the people depending on the robots should experience, count how often that happens, and let the gap steer priorities. The Atlas traces the practice to a tiny production team in the early 2000s, and the idea transfers easily: replace “web page” with “pick request” and the logic holds.

What would a robot-floor indicator look like?

In SRE an indicator is good outcomes divided by valid outcomes. On a warehouse floor, a valid event might be a pick request that reaches the system, and a good one might be a request completed within an agreed time. Measure it close to the customer, which here could mean the packing station rather than the robot’s own controller. The reference adds a useful detail about timing: report the share of tasks finished within a limit, not an average, because an average hides the handful of orders that waited far too long.

One more subtlety. A task that fails instantly counts against availability, yet it should not flatter the timing figure by being counted as “fast”. Keep the two measures separate.

Why not promise that robots never stop?

Because it cannot be kept and chasing it would freeze improvements. The Atlas is direct that perfection is the wrong goal for nearly every service, and each extra step of reliability can cost vastly more than the last. A fleet aiming at five nines would exhaust a whole month’s allowance in about 26 seconds of total stoppage, which no human supervisor can respond to in time.

Better to set something honest, such as 99.9 percent of picks on time over a rolling four weeks. That window includes every weekday the same number of times, so a busy Monday is compared fairly.

What is the “error budget” in plain terms?

It is one minus the objective, a limit on how much failure is tolerable. At 99.9 percent over 28 days, that is about forty minutes of bad time or a thousand missed picks per million. Think of it as the number of late orders your customers can forgive in a month.

The supervisor in our story drew the budget on the wall. When half was gone by mid-month, the team postponed a firmware update to the robots’ navigation module. When the budget was barely touched, they felt free to try a new routing rule. The chart settled arguments that had previously relied on volume and seniority.

How many robots should be idle on purpose?

This is the capacity question, and the Atlas supplies a lovely rule of thumb. If you want a group to survive two failures, you plan for N+2. With three units, each can run at only a third of its capacity in normal times; with five, about 59 percent. It sounds wasteful until the first morning two chargers fail at once and the floor keeps moving.

The reference also points out that moving work to other units is generally safer than adding new ones in a hurry, since provisioning is where mistakes happen. In robotics terms: rebalance missions across the fleet before you rush new hardware onto the floor.

What about updates to robot software?

Roughly seven in ten outages come from changes made to live systems, so releases deserve care. A canary approach sends a change to a small slice first. If five percent of the fleet gets the update and a fifth of their tasks fail, the overall failure rate rises by only one percent, small enough to spot and to reverse. For a view of metrics that factory managers track alongside this, this overview of key performance indicators for robotics operations is a useful companion.

What if our fleet depends on a vendor’s cloud service?

Then your promise is capped by theirs. The Atlas offers a tidy guideline called the rule of the extra nine: every dependency ought to beat the thing built upon it by one full nine. If your mission-planning service relies on a hosted map or scheduling component that promises 99.5 percent, you cannot honestly promise the floor 99.9 percent without a fallback, such as cached routes the robots can follow when the hosted service blinks. Writing the dependency numbers next to your own is a humbling and useful exercise, and it turns vague worries into specific design tasks.

Who gets the midnight call?

The Atlas suggests a rota of about eight people for a single site covered around the clock, and a shift in good health sees only a couple of incidents across twelve hours. Written playbooks matter too; the reference reports roughly a threefold improvement in time to repair when responders have a script to follow. For a smaller floor, say honestly which stoppages justify a night call and which can wait for morning.

Is repetitive manual work part of the problem?

Very much so. Toil is manual, repeated, automatable work that grows with the system and builds nothing lasting, like re-seating a stuck charging contact by hand every shift. Aim to keep it under half of a technician’s time; industry surveys report typical figures around a third. Count it, then automate the worst offender first. If your site is rolling out guided vehicles, the complete guide to warehouse automation with AGVs shows where such chores tend to appear.

What happens after a bad night?

Hold a review without hunting for a culprit, and list actions with a single owner and a deadline each. The Atlas treats reviews that never close their actions as a standard failure. If a single night swallowed a fifth or more of the allowance, make at least one fix a priority.

How did the supervisor’s story end?

Within a quarter, her team had a 99.9 percent objective for on-time picks, a budget on the wall, three scripts that removed their worst chores and a habit of reviewing every notable stoppage. The robots were not noticeably more reliable on day one, but decisions got calmer and faster. That, quietly, is the whole point of the discipline. Start with one flow, one indicator and one window, and let the numbers carry the conversation.