Downtime reasons log: from records to action

During a day shift the line stops several times: five minutes for labels, twenty for a setup, another ten because the operator was waiting for the supervisor. At the end of the shift the log gets one line: “downtime 35 min, technical reasons”. A manager cannot decide anything with that record. Without a log, the conversation about downtime comes down to impressions: everyone remembers the most unpleasant case, not the most frequent one.

A downtime reasons log is not for finding someone to blame. It answers three questions: what exactly stopped, how much time passed before the response and before work resumed, and which obstacle recurs most often. For that, the record is made during the event, not from memory, and the observation is kept separate from the assumption.

Before the first record, agree on a few rules; otherwise data from different shifts cannot be compared.

• The unit of measurement. Are you measuring a worker interval, an area event or equipment downtime from a separate data source? Two workers waiting 10 minutes at the same time make 20 person-minutes, not 20 minutes of machine downtime.
• The reasons list. 8–12 reasons a worker understands: no material, breakdown, setup, waiting for the supervisor, safety issue. “Other” only with a comment.
• What counts as a response. For example, the supervisor confirmed they see the problem and said who is handling it.
• Who verifies the cause. The worker reports what they see; the supervisor or process engineer records the verified cause.
• The threshold. Whether you record short stops under two minutes. If you do, record all of them, not only the ones someone remembered.

Also decide who fills in the log. The most accurate records come from the person who sees the stop — the operator on the line. The supervisor adds the response, the verified cause and the action. If only the supervisor fills the log at the end of the shift, it becomes a record from memory again.

Record. Date, shift, area, equipment or workstation, who reported it and through which channel. The channel matters: a phone call to the supervisor leaves no timestamp anywhere.

Event. What exactly was observed, without conclusions: “no labels at the line”, not “the warehouse let us down again”. Separately: whether work stopped fully, partly or not at all, and a photo if it explains something.

Time. Four timestamps that must not be mixed: start, first report, supervisor response and work resumed. Time to response and time to resume are different measures, and both are useful.

Cause. First the cause as the worker reported it, then the verified cause with the name of whoever verified it and the code from the reasons list. If the reported cause was not confirmed, that is also a result.

Action. What was done to resume work and what needs to change so it does not happen again — with an owner and a deadline.

Review. Links to similar records and a field for gaps: what we do not know and why. Do not hide gaps; they affect the conclusions.

How to read the log. Once a week, group records by reason and area and look at three numbers: the number of cases, the total time to resume and the typical time to response. The most frequent reason is not always the most expensive: ten three-minute stops can hurt more than one half-hour stop because each one breaks the rhythm of the line. Pick one reason and see the action through before moving to the next.

This example is fictional: it shows how one record turns into an action.

• Area: filling line 1, day shift.
• 10:00 an operator reports: “no labels, the line is stopped”. Work has stopped.
• 10:02 a second operator in the same area reports the same thing — this is the same case, not a new one.
• 10:04 the supervisor acknowledges and calls the warehouse. Time to response: 4 minutes.
• 10:31 labels delivered; at 10:33 the line is running. Area stop: 33 minutes; loss for two operators: 66 person-minutes.
• Reported cause: no labels. Verified cause: labels were in the warehouse, but the request was not sent at the end of the previous shift.
• Action: the item “remaining labels and request for the next shift” is added to the shift handover checklist; owner — the area supervisor, deadline — Monday.

A month later, compare the number of label stops on similar shifts and check whether all of them were recorded.

• Assumption instead of fact. “Broke because of the operator” is a conclusion that still needs checking.
• Mixing units. Person-minutes are added up as machine downtime minutes, and losses look inflated.
• Recording only long stops. Short recurring stops often cost more than one big one.
• Closing the record at the response. The supervisor responding does not mean work has resumed.
• “Other” without a comment. If it covers more than a fifth of the records, revise the reasons list.
• Penalties for reporting. When downtime lowers a score, people stop reporting it; the downtime does not go down.
• A log nobody reviews. If records are never discussed, workers quickly stop making them. Show the team which actions came from their reports.
• Comparing incomplete periods. A reduction in recorded losses can also mean incomplete reporting. Check that before drawing conclusions.

In Vakhta a worker presses “Report a problem” in the Telegram bot: chooses a reason from the list, adds a comment and, if needed, a photo, and answers whether work has stopped. Reports for the same area and reason within a short window attach to the open incident.

The shift supervisor is notified. If there is no response within the time set for the severity level, the incident escalates; safety reasons escalate at once. The worker’s personal downtime interval and the area incident are stored separately, and the time-loss report shows recorded intervals by category and reason. Reporting downtime never reduces the worker’s points.

1. Record: date, shift and area
2. Record: equipment or workstation
3. Record: who reported and through which channel
4. Event: what exactly was observed, without conclusions
5. Event: work stopped — yes, partly, no
6. Event: photo or other evidence
7. Time: stop started
8. Time: first report
9. Time: supervisor response
10. Time: work resumed
11. Time: unit — area minutes, person-minutes or equipment minutes
12. Cause: as reported by the worker
13. Cause: verified, and by whom
14. Cause: code from the reasons list
15. Action: what was done to resume work
16. Action: what to change, owner and deadline
17. Review: similar records in the period
18. Review: gaps and unknown data