What happens if the network fails during robot operation?

What happens if the network fails during robot operation is a design question rather than a robot question, and the honest answer is that a well-built system degrades instead of stopping. A well-designed robot integration degrades rather than stops: autonomous forklifts complete the task already issued, hold in a safe state, and the fleet layer queues completions and replays them once the link returns. Online shopping accounted for 28.8 per cent of all retail sales in Great Britain in September 2026, Office for National Statistics figures show, and an e-commerce fulfilment site carries that volume through November and December with almost no slack. For an operations director, the worry is rarely a robot behaving badly. It is a ten-minute wireless drop at 02:00 that leaves half-finished moves, pallets parked in cross-aisles, and a host record that no longer matches the floor, followed by a manual reconciliation that swallows the first hour of the morning shift.

Why a short network drop causes a long recovery

Most fulfilment sites were wired for handheld scanners and voice picking, not for continuous machine control. A scanner that loses signal for thirty seconds annoys a picker. The same thirty seconds reaches a robot fleet as a gap in a conversation that was expecting a reply, and the recovery is slower than the outage that caused it.

Three things usually combine. First, coverage is uneven in exactly the places robots work hardest, and on the large campuses around Magna Park, DIRFT and SEGRO East Midlands Gateway that means high-bay aisles where racking blocks signal, dock approaches where roller shutters open and close, and chilled areas where the fabric of the building absorbs it. Second, the host system and the fleet layer are often joined by a single synchronous interface, so a timeout on one side is read as a refusal rather than a pause. Third, nobody owns the robot network. IT owns the corporate wireless, operations owns the trucks, and the gap between them is where an outage turns into an argument.

There is also a reporting trap. During a drop, the fleet layer keeps a complete picture of what each vehicle did, but the host system does not receive it. When the link returns, the two sides disagree, and the question of which one is right has to be answered under time pressure at the worst moment of the week.

Lever one: define the detached behaviour before anyone quotes for the work

Decide, in writing, what each class of vehicle does when the link goes quiet, and make it part of the specification rather than a discovery made during go-live. The sensible default is finish and hold: the robot completes the move it already accepted, places the load in a validated location, reports locally, and waits. It does not start speculative work, and it does not park where it blocks a fire route or a dock approach. Agree the hold positions by zone with the shift managers who will walk the floor during an outage, and mark them. Agree, too, how long a vehicle waits before a supervisor is paged. On a three-shift site the escalation route at 02:00 should not be the one that works at 14:00.

Lever two: give the fleet layer a buffer, an idempotency key and a replay plan

This is the technical heart of the answer. The fleet management layer should hold a queue of accepted tasks and completed-but-unacknowledged results, each carrying a unique identifier that the host system can recognise a second time and safely ignore. That single design choice, idempotent messaging, is what prevents a replayed batch from double-posting stock movements when the link returns. Underneath it, the vehicles should speak an open interface. NCSC guidance on operational technology makes the wider point that availability and safety, not confidentiality, are the governing priorities in environments like this, which is why the robot network is normally segmented from corporate traffic. FlyWei's M4 fleet manager is built to run detached for a defined window and to reconcile on reconnection rather than replay blindly, and the robot dispatch software holds the business rules that decide what may resume automatically.

Lever three: treat the robot network as part of the work equipment

A network a robot depends on is not ordinary office infrastructure. Under the Provision and Use of Work Equipment Regulations 1998, an employer must ensure work equipment is maintained in an efficient state, in efficient working order and in good repair, and the HSE guidance on PUWER extends that duty to inspection and to the competence of the people using it. In practice this means the access points, switches and aerials that carry robot traffic belong on the planned maintenance schedule beside the trucks, with the same inspection records. BS EN ISO 3691-4, the BSI standard for driverless industrial trucks, expects the safety functions on each vehicle to operate independently of any supervisory link, so a connection loss is a stoppage rather than a hazard. Say this plainly in the risk assessment, because an auditor will ask.

Lever four: rehearse the outage during commissioning

An outage drill is the cheapest insurance available on an automation project, and the only honest way to discover what the specification actually bought. During commissioning, pull the link deliberately: once briefly in a busy aisle, once for half an hour against the host interface, and once with a forced duplicate batch on reconnection. Record how long each vehicle took to reach a safe hold, what the supervisors saw on screen, and whether the stock record survived the replay intact. Repeat the drill before peak with the team who will actually be on shift in late November, not the project team. Sites that rehearse treat a wireless drop as a known event with a runbook. Sites that do not, discover their design assumptions at 02:00 on the busiest night of the year.

A well-designed robot integration degrades rather than stops: autonomous forklifts complete the task already issued, hold in a safe state, and the fleet layer queues completions and replays them once the link returns.

What FlyWei does here

FlyWei is an independent UK systems integrator of autonomous forklifts and AMRs, and because FlyWei is vendor neutral it integrates machines from several manufacturers rather than defending one product line. On a resilience question that matters, because the weak point is almost never the truck. FlyWei specifies the detached behaviour per vehicle class, sets the hold positions with your shift managers, and designs the connection between the fleet and your existing ERP or WMS so that it buffers, de-duplicates and reconciles instead of replaying blindly. The M4 fleet manager runs the traffic rules, task assignment and charging strategy for a mixed fleet, including lifting AMRs working goods to person, and keeps commanding vehicles for a defined window when the host is unreachable. The robot dispatch software carries the business rules above that, deciding what resumes automatically and what waits for a person. FlyWei then writes the outage into the acceptance tests, so the promised behaviour is the behaviour you witness before you sign. For the wider picture, see our guides on what a robot fleet exchanges with an ERP and whether you need to replace your WMS to use AMRs.

Frequently asked questions