Downtime Log Template

The reason most downtime logs produce no improvement is that they record a single number per stoppage, and a single number is unactionable. A line that reads three hours and eleven minutes against a seized bearing tells you the asset failed and the asset came back, and every conversation that follows is about whether the repair could have been quicker. That conversation has a predictable shape: the maintenance team is asked to respond faster, they point out they responded as fast as they could, and nothing changes because nothing measurable has been identified. Breaking the same stoppage into four timestamps changes the conversation entirely, because it turns one number into a sequence with different owners. The minutes between the asset failing and anybody noticing belong to production and are fixed with an alarm. The minutes between somebody noticing and somebody being told belong to the reporting route. The minutes between being told and arriving belong to resourcing and call-out arrangements. Only the final stage belongs to the technician holding the spanner, and on most sites that stage is the smallest of the four. The second structural decision worth protecting is the reason code list. It has to be fixed before the first entry and it has to exclude free text entirely, which feels restrictive to whoever is logging and is the only thing that makes the log analyzable. A free text field produces bearing failure, bearing seized, seized bearing, brg failure and bearing went, which are one problem recorded five ways and will never group into anything. Eleven codes with a stated owner and a stated preventable-by is enough for any site, and if a stoppage genuinely does not fit one of them, that is a signal to review the list deliberately rather than to let the person logging invent a category at the end of a bad shift.

Thirty one percent against sixty nine percent is the only pair of numbers on this page that changes what anybody does on Monday. Twelve hundred minutes lost across a month reads as a maintenance problem, and presented as a single figure it will be handled as one: a review of the maintenance regime, perhaps a conversation about response times, possibly a question about whether the team is quick enough. The split says something different and more useful. Less than a third of the time lost was spent repairing anything. The other two thirds was the line standing still while somebody noticed, somebody was told, somebody traveled, a part was found, an isolation was arranged or a specialist was located. None of that is improved by a faster technician, and all of it is improved by things that cost less than most maintenance interventions: an alarm on the line, a clearer call-out route, a small change to the spares holding, a pre-authorized permit for routine isolations. The rest of the period is ordinary. Fourteen stoppages, eleven of them unplanned, mean time to repair of eighty six minutes and mean time between failures of a little over two thousand, which is the pair to watch across periods rather than within one. At a rate of nine hundred an hour the month cost just over eighteen thousand, and the worst single asset accounted for four hundred and twelve of those minutes across six stoppages. The jobs raised against each of these stoppages are tracked on the work order tracking template, the cost and service history that accumulates against each asset belongs on the maintenance log, and the routine that should be reducing the failure count in the first place is the preventive maintenance log.

The practical value of this split is that it moves the problem to people who can actually solve it, and it does so with evidence rather than opinion. Every site has a version of the same unproductive exchange: downtime is high, maintenance is asked to improve it, maintenance replies that the team responded as quickly as it could, and both statements are true. The split resolves it by showing which stage grew. If the time between a failure and anybody noticing is significant, that is an instrumentation and alarm question and it belongs to whoever runs the line, not to the person who eventually fixed the machine. If waiting for parts dominates, it is a stock decision, and the log turns it from a complaint about stores into a figure with a cost attached, which is the only form in which a stock argument has ever been won. If waiting for a permit or isolation is large, it is a process question, often solvable with pre-authorization for routine work on known assets. Only when active repair is the dominant stage is the conversation genuinely about maintenance capability, and in most periods it is not. That is also why the actions section asks for two separate lists. Reducing failures changes the maintenance regime and takes months to show up in the time between failures. Reducing waiting changes an arrangement and shows up in the next period. Teams that conflate the two tend to do only the first, which is slower, more expensive and smaller than the opportunity sitting in the other column. The job queue and how long each job has been open is a different document, the work order tracking template, and the checks that should be catching these failures before they stop anything are on the equipment maintenance checklist.