Why keep your own robot fleet uptime log?
The robot vendor reports from its fleet manager, but the service agreement is usually measured on availability and response time. Your own record of every stop, with the time you called the vendor and the time they responded, gives you figures to review with them at the monthly service meeting, and shows which robots and which causes take most of the downtime.
This file holds a robot register, an incident and downtime log, and monthly KPIs: availability, mean time between failures (MTBF), mean time to repair (MTTR), incidents by category and safety incidents.
How to use the log
- Set up: operating hours and days, and the availability and response targets from your contract.
- Register the robots: a unique ID for each robot, its type and the date it entered service.
- Log every stop when it happens: stop and back-in-service times, category, whether it needs a repair and whether it is safety-related.
- Log the vendor contact: when you called, when they responded and the ticket number.
- Read the monthly KPIs: type the first day of the month, then review the robots below target and the biggest category.
How does the log calculate the KPIs?
The log separates a failure that needs a repair or a part from an operational stop such as a blocked path or a network drop: both lower availability, but only failures count in MTBF and MTTR. An open incident with no back-in-service time counts as downtime until the as-of time.
Sources
- Reliability Magazine, Maintenance and Reliability KPI Reference, 22 July 2026 (MTBF = operating time ÷ failures, MTTR = repair time ÷ repairs, availability = uptime ÷ (uptime + downtime), citing SMRP and EN 15341). Source: Reliability Magazine.
- SMRP Best Practice Metric 3.5.1, Mean Time Between Failures. Source: SMRP.
- M. P. Groover, definition of availability for vehicle-based transport systems (chapter 10, section 10.6). Source: NIT Srinagar lecture notes. Last reviewed 21 October 2026.
Worked example: two robots below target in October
The figures in the file are examples: six robots scheduled 20 hours a day, seven days a week, with a 98% availability target in the contract.
- In October (31 days) each robot has 20 × 31 = 620 scheduled hours.
- R-03 stopped 4.5 hours with a worn drive wheel and 8.5 hours after a failed software update: 13 hours, so availability is 1 − 13 ÷ 620 = 97.9%, below target.
- Two failures needing repair: MTBF = (620 − 13) ÷ 2 = 303.5 hours and MTTR = 13 ÷ 2 = 6.5 hours.
- The autonomous forklift R-06 stopped 16.5 hours because its battery would not charge: availability 97.3%, and the vendor responded after 105 minutes, over the 60-minute target.
- Battery or charging is the biggest cause of downtime in the month, so it is the first item at the service meeting.
Common mistakes in robot uptime records
- Logging only big failures. Short, repeated stops add up to a lot of time.
- Relying only on the vendor's report. Your log lets you compare their figures with yours.
- Not recording when you called. Without it you cannot measure the contract response time.
- Mixing operational stops with failures. A blocked path is a process problem, not a robot fault.
- Ignoring small safety stops. Every safety stop caused by a person deserves a review.
What the template does not cover
The log calculates what you record; it does not read data from the vendor's fleet manager. A stop counts in the month it started, and every robot is assumed scheduled for all operating hours. Targets and hours on Settings are examples: take them from your contract. For near misses with people, also use the Near-Miss Report Form and Log.