- \n
- Most maintenance windows are chosen from the schedule, not from real machine time.<\/li>\n
- Automatic stop data reveals real idle periods, recurring micro-stops and changeovers.<\/li>\n
- Four weeks of stop data is usually enough to map weekly patterns on a line.<\/li>\n
- Ranking the backlog by lost production time complements criticality analysis.<\/li>\n<\/ul>\n<\/div>\n
Why maintenance windows are often picked from the calendar, not the shop floor<\/h2>\n
A solid starting point is Maintenance Planning: 7 Best Practices That Cut Downtime<\/a>, written by the FastMaint Team at SMGlobal. The article separates planning, which answers the “what” and “how”, from scheduling, which answers the “when” and “who”, and walks through asset records, criticality analysis, job templates and planner roles. On prioritization, the FastMaint Team puts it simply: “Criticality-based prioritization ensures your planning effort and resources go where the impact is greatest.”<\/p><\/blockquote>\n
That article gives you the method. This one focuses on a single input to that method: knowing, with real data, when your machines are actually stopped, why, and for how long. In most plants, maintenance windows are chosen from the production schedule, the shift pattern or a fixed weekly slot. The schedule says the press runs Monday to Friday on two shifts, so maintenance gets Saturday morning. The problem is that the schedule describes intended machine time, not real machine time.<\/p>\n
On the shop floor, lines wait for material, for an operator, for a quality release or for the next order. Changeovers take longer than planned. Short stops of a few seconds to a few minutes add up without anyone writing them down. Each of these is a hidden window, or a hidden warning, that a calendar-based approach never sees.<\/p>\n
What automatic stop data reveals that the production plan does not<\/h2>\n
When stops are captured automatically at the machine, rather than typed into a log at the end of the shift, three patterns usually become visible within a few weeks.<\/p>\n
- \n
- Real idle periods.<\/strong> Recurring slots where the machine is stopped but not because of a fault: waiting for upstream parts, end of a production campaign, a lunch break that is not covered, a night shift that ramps up slowly. These are natural candidates for short maintenance tasks.<\/li>\n
- Recurring micro-stops.<\/strong> Short, repeated stops that rarely trigger a work order but often signal wear, misalignment or a sensor drifting out of tolerance. Their frequency and timing tell you which asset is degrading before it breaks.<\/li>\n
- Changeovers.<\/strong> Planned stops that already take the machine out of production. If a changeover regularly lasts 40 minutes, for example, some inspection or lubrication tasks can be done in parallel instead of requiring a separate stop.<\/li>\n<\/ul>\n
None of this replaces criticality analysis or a good job plan. It gives the scheduler a factual map of machine time, so the “when” is based on what the line actually does rather than what it is supposed to do.<\/p>\n
![\"Four](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/10\/teeptrak-maintenance-windows-en.png\")
<\/figure>\nA step-by-step method to choose maintenance windows from stop data<\/h2>\n
Here is a practical sequence you can run on one line before rolling it out more widely.<\/p>\n
- \n
- Collect at least four weeks of automatic stop data.<\/strong> You need start time, duration and a reason category for every stop. Four weeks is usually enough to see weekly patterns and separate one-off events from recurring ones.<\/li>\n
- Map stops by hour and by day.<\/strong> Build a simple heat map: days of the week in columns, hours in rows, total stop minutes in each cell. Recurring low-activity slots stand out immediately.<\/li>\n
- Separate the stop types.<\/strong> Split the map into unplanned breakdowns, micro-stops, changeovers and organizational waits (material, staffing, quality). Only the last two are good candidates for planned maintenance windows.<\/li>\n
- Match task duration to window length.<\/strong> Use your job plans to sort tasks by duration. A recurring 20 minute wait suits a visual inspection or a filter change; a full overhaul still needs a dedicated stop, but you now know which shift or day costs the least output.<\/li>\n
- Book the window and measure what happens.<\/strong> After each planned window, check that the following runs show fewer breakdowns and fewer micro-stops on the treated asset. If they do not, the task, the frequency or the window needs adjusting.<\/li>\n<\/ol>\n
The aim is not to squeeze every task into a gap. It is to stop guessing, and to give production and maintenance a shared, factual basis for negotiating machine time.<\/p>\n
Prioritizing the maintenance backlog with real stop patterns<\/h2>\n
The same data helps decide what goes first. The FastMaint Team’s maintenance planning best practices<\/a> recommend refining estimates from history: “Use your CMMS work order history to compare planned versus actual times, parts consumption, and labor requirements.” Automatic stop data adds the production side of that history: how much output each open issue is costing, and how often it strikes.<\/p>\n
The table below shows one way to combine the two views. The example values are illustrative, not measured results.<\/p>\n
- Map stops by hour and by day.<\/strong> Build a simple heat map: days of the week in columns, hours in rows, total stop minutes in each cell. Recurring low-activity slots stand out immediately.<\/li>\n
- Recurring micro-stops.<\/strong> Short, repeated stops that rarely trigger a work order but often signal wear, misalignment or a sensor drifting out of tolerance. Their frequency and timing tell you which asset is degrading before it breaks.<\/li>\n
- Real idle periods.<\/strong> Recurring slots where the machine is stopped but not because of a fault: waiting for upstream parts, end of a production campaign, a lunch break that is not covered, a night shift that ramps up slowly. These are natural candidates for short maintenance tasks.<\/li>\n