Here is my verdict up front: running AMRs on the night shift saves you labor, but it tests your contingency planning. The robots have no problem working around the clock. The real question is what happens in the one minute a bot gets stuck — because at 3 a.m., nobody is there to give it a kick.
I have watched plenty of AMR projects demo beautifully in daylight: fleets gliding through aisles, dispatch running smooth, ROI spreadsheets glowing. Then someone brings up "fully unattended, 10 p.m. to 6 a.m." and the room goes quiet. Vendors will tell you their robots support 24/7 unmanned operation, and technically they are right — Brightpick's picking robots were already doing lights-out overnight fulfillment back in 2025, and Locus Robotics' fleet has passed 22,000 robots with over 8.5 billion picks logged. But "can run" and "should run alone all night" are two different things. With nobody on site, every exception has to resolve itself through a playbook, not a person walking over.
If a Bot Gets Stuck at 2 a.m., Who Goes and Pushes It?
AMR exceptions fall into three buckets: self-resolving, remotely resolvable, and needs-hands-on-site. During the day you have all three. At night you only have the first two. So the first rule of night-shift scheduling is simple: only assign work that can never land in bucket three.
Self-resolving stuff — rerouting around a temporary obstacle the LiDAR picked up, the fleet manager reprioritizing the task queue — gets handled in seconds. Remotely resolvable stuff — a bot failing dock alignment at the same station three times in a row, so someone takes over teleoperation from the monitoring console and nudges it — is fine too. Bucket three is where nights go to die: a cracked pallet deck jamming the forks, a leaning carton blocking the safety scanner, two bots deadlocked in a narrow aisle. With nobody on the floor, those become hard stoppages that sit there until morning.
I learned this one the expensive way. In 2023 I helped a 3PL in Ontario bring up an AMR fleet. A month of smooth daytime running, confidence through the roof, and we switched on unattended nights. On night three, a pallet shifted half an inch in a turn — just enough to clip the safety scan zone. The bot e-stopped on the spot. The bots behind it queued up, one after another, and the whole aisle seized. The morning crew walked in at six to find a conga line of a dozen dead robots. Since then my rule has been: nights are for full-pallet, full-case moves on fixed routes only. Loose pieces, odd-shaped freight, inbound receiving with mixed pallet quality — that runs in daylight when someone can intervene. Pallets look standardized. They are not. Deck thickness and nail patterns vary by supplier, and you do not want to gamble on that at 2 a.m.
You also need an on-call person who lives close enough to be on site within 30 minutes. Not a night-shift employee — an insurance policy. This person needs authority to restart fleet services remotely and release task locks manually. Plenty of projects skip this role, figuring "we have remote monitoring." Then something real happens, and the person staring at the dashboards can watch the disaster in high definition but cannot fix any of it.
Remote Monitoring: Which Numbers Actually Matter?
Unattended does not mean unwatched. The right setup is nobody on the floor, but somebody watching from somewhere — a central monitoring room, or a duty engineer's phone. What matters is what they watch. Staring at a wall of camera feeds is the least useful option; eyes get tired, and exceptions still slip through. Night monitoring comes down to four numbers.
First, task completion rate. Completed moves per hour from the fleet manager, plotted as a curve. On a normal night that line is flat. When it falls off a cliff, you have bots going down in bulk — and you will see it here a good half hour before any camera shows you anything.
Second, exception stops and longest single-bot stall. I run two alert tiers: a bot sitting still for more than 10 minutes triggers a push notification; more than 30 minutes triggers a phone call to the on-call. Do not set thresholds tighter than that. Bots legitimately idle while waiting for charge or tasks, and too many alerts just train the duty engineer to ignore all of them.
Third, the low-battery queue. Charging stations are the bottleneck at night, and dozens of bots taking turns on chargers is normal. What you watch is how many are waiting. A long charge queue means the fleet starts the morning shift undercharged — which means the whole night was wasted.
Fourth, Wi-Fi drop-and-reconnect counts. Roaming dropouts are the invisible killer of unattended nights. One dropout is fine; the bot caches locally and finishes its move. Dozens of dropouts across a night, and task latency compounds silently. Nobody watches this number in daylight. At night it is mandatory.
Alert channels need tiers: push, text, phone call. Push-only is the same as no alerting — who wakes up for a push notification at 3 a.m.? Genuinely dangerous exceptions must be able to ring a phone. And yes, this sounds obvious, but I have personally seen a duty engineer sleep through seven alerts because his phone was on Do Not Disturb. The monitoring wall can go dark. The duty phone cannot go silent.
Wi-Fi Down, Power Out, Deadlock: What Is the Playbook?
The three nastiest night-shift failures need written, rehearsed playbooks — not procedures living in somebody's head.
Network outage. Get one fact straight first: AMRs do not immediately die when the Wi-Fi drops. Modern bots cache locally, finish the current task, and park somewhere safe. The real damage is that the fleet manager cannot dispatch anything new, so the fleet gradually goes idle. The playbook has three lines. One, redundant network paths: dual uplinks, and the AP controllers plus core switches on UPS. Two, walk the floor and map the dead zones — signal with full racks looks nothing like signal in an empty building during commissioning. Three, set a heartbeat timeout: no heartbeat for, say, five minutes, and the fleet drops into conservative mode automatically. Finish cached tasks, take no new ones, return to charge positions and wait. No heroics.
Power outage. The bots have batteries; they do not care about a blackout. Everything that tells them what to do cares: servers, network gear, chargers. So the playbook is tiered. Core networking and the fleet manager go on UPS, sized to bridge short outages or hold until the generator kicks in. Chargers can go dark — the bots have charge. But the restart sequence after power returns has to be written in stone: network first, then servers, then wake the vehicles in batches. Power everything at once and you get a task storm that crushes the system on boot. Rehearse this twice in daylight, because nobody thinks clearly at 3 a.m. during a real outage.
Deadlock. Two bots nose-to-nose in a narrow aisle, neither yielding. A good fleet manager has deadlock detection and, after a timeout, orders one bot to back out. But nights add a wrinkle: deadlock detection assumes the map matches reality, and at night there may be temporarily staged pallets narrowing an aisle that was clear at commissioning. The playbook: mark night-restricted aisles as no-go zones with virtual walls, and run deadlock-prone narrow lanes one-way only at night. Do not bet on the algorithm solving it every time. Physical separation is more reliable.
Finally, when should you not run AMRs unattended at night at all. Three red lines. One, a new site or new process that has not run clean for at least a month — get the daytime exception rate down first. Two, mixed-SKU work with volatile packaging, where the exception types are unpredictable and no playbook can cover them. Three, operations where pallet or container quality is out of your control, like third-party inbound with a mixed bag of pallets — in daylight a person can reject a bad pallet; at night the robot cannot. Interact Analysis projects more than 53,000 sites will have deployed AMRs or AGVs by the end of 2025, and enterprise fleets typically run 50 to 400 bots per site. The hype is real, but hype does not make every warehouse ready for lights-out. More bots means a higher probability of simultaneous exceptions at night, so the contingency plan has to scale up with fleet size — not scale down because "the robots are smart."
One question to leave you with: when was the last time anyone actually read your fleet's exception log? If the answer is "during go-live week," hold off on the unattended night shift.
