Robot fleet alerts were meant to make Meera’s job easier. As the night-shift floor supervisor at a mid-sized fulfilment centre, she carried a tablet that showed messages from forty autonomous mobile robots moving totes between storage aisles and packing stations. In the first weeks after go-live, the tablet chimed constantly: a robot pausing because a person stepped into its path, another reporting a battery at thirty percent, a third rerouting around a pallet left in an aisle, a charger handshake retried and recovered. By the second month, Meera had turned the volume down. By the third, she checked the tablet only when a picker came to tell her something was wrong. One night that habit meant a robot sat stuck at a blocked lift for most of an hour, holding up a whole wave of orders, while its warning waited unread among a hundred others. This guide follows the steps her team used to turn that tablet back into something people trust.

Step 1: Collect a fortnight of robot fleet alerts and label them

The operations lead, Daniel, started by exporting two weeks of messages from the fleet management software. He and Meera sat down with a spreadsheet and added one column: what did someone do about it? Most entries had the same answer, nothing. Robots paused for people and resumed on their own. Batteries dropped and the scheduler sent robots to charge, exactly as designed. Reroutes happened and completed. Only a small fraction of messages had needed a human to walk over, clear an obstruction, reset a robot or call maintenance. That single column changed the conversation from “the tablet is annoying” to a precise list of what was worth seeing.

Step 2: Separate what the fleet handles from what people must handle

Modern fleets resolve many situations themselves. Path conflicts, low batteries and minor reroutes are usually managed by the scheduler, a point covered in our guide to fleet management basics for teams new to robots. Daniel’s team sorted every message type into two groups: events the system resolves automatically, and events that only a person can fix, such as a physical blockage, a robot that has stopped responding, or a lift or door that will not open. The first group moved off the tablet and into a shift log reviewed each morning. The second group stayed.

Safety events were handled separately from the start. Emergency stops and anything touching the site’s safety procedures remained visible and were never demoted, in line with the principles explained in our overview of robotics safety standards in plain terms.

Step 3: Turn bursts into a single message

The stuck-lift night revealed another pattern. When the lift failed, three robots queued behind it, and each sent its own “unable to proceed” warning every few minutes. To someone glancing at the tablet, it looked like general chatter. Daniel configured the fleet software to combine messages that shared a location and arrived within a short window into one event: “lift L2 blocked, three robots waiting”. One clear message about a place is far easier to act on than a dozen scattered ones about individual robots.

Step 4: Give each remaining alert a time-based trigger

Many conditions sort themselves out within a minute. A robot waiting for a person to step aside, or a brief wireless dropout near the loading dock, does not need anyone’s attention unless it persists. The team added a waiting period to each human-facing alert: a robot had to be stuck for several minutes, or out of contact for more than a short interval, before the tablet chimed. That small change removed most of the remaining false alarms without slowing the response to genuine problems.

Step 5: Retire messages nobody has acted on

Some alerts had been switched on during commissioning to help the integrator tune the system, such as detailed localisation confidence warnings and charger diagnostics. They were useful to engineers setting the fleet up but meant nothing to a supervisor on a busy night. Daniel removed them from the tablet entirely, kept them available in the engineering logs, and wrote a short note explaining each decision so the integrator could restore any of them if needed.

Step 6: Write the “walk over now” rule

Finally, Meera and Daniel agreed a one-line standard and taped it beside the supervisor’s desk: the tablet chimes only when a robot needs a person to physically help it, or when orders will be delayed if nobody acts within ten minutes. Every alert type was checked against that sentence. Anything that failed it went to the morning log.

Other industries have been through the same exercise with their own systems. IT operations teams, for instance, read publications such as TheAIOps.com for ideas on correlating and filtering alerts across complex infrastructure, and Daniel found the thinking there carried over neatly to a warehouse floor.

Step 7: Review it every month

The fleet changes over time. New robots arrive, layouts shift for peak season, firmware updates add new message types. Each month, Meera’s team looks at every tablet alert from the previous weeks and asks whether it deserved to interrupt someone. New message types start in the log by default and only move to the tablet once they have proven they need a human. For teams scaling up, our guide to running autonomous mobile robots day to day covers other routines worth folding into that review.

What the night shift looks like now

On a typical night, Meera’s tablet chimes a handful of times. Each chime is a robot that genuinely needs help, usually with a location and a short description attached. She answers every one, because experience has taught her that each one is real. The lift has failed twice since, and both times a supervisor was there within minutes. Fewer messages did not mean less awareness of the fleet. It meant the right person noticing the right problem quickly, which was the point of the tablet all along.