{"id":157053,"date":"2026-11-02T13:00:58","date_gmt":"2026-11-02T13:00:58","guid":{"rendered":"https:\/\/teeptrak.com\/maintenance-dashboard-sme-production-data\/"},"modified":"2026-11-02T13:00:58","modified_gmt":"2026-11-02T13:00:58","slug":"maintenance-dashboard-sme-production-data","status":"publish","type":"post","link":"https:\/\/teeptrak.com\/en\/maintenance-dashboard-sme-production-data\/","title":{"rendered":"Maintenance dashboards for smaller plants: the production data that really belongs"},"content":{"rendered":"
This article is for maintenance managers, plant managers, production directors and managers, and continuous improvement and methods leads in small and mid-sized manufacturers who are setting up or reworking a maintenance dashboard. It shows which production data really belongs on it (downtime with duration and reason, micro-stops, availability, MTBF and MTTR from automatically captured timestamps), what to leave off, and who looks at what every day.<\/p>\n
\n
In short<\/div>\n
\n
A maintenance dashboard needs a few data points taken straight from the machine.<\/li>\n
Downtime with duration and reason is the base for every other metric.<\/li>\n
MTBF and MTTR are only reliable when they come from automatic timestamps.<\/li>\n
Every metric needs an owner and a fixed review rhythm.<\/li>\n<\/ul>\n<\/div>\n
What Alphalink writes about digital maintenance platforms<\/h2>\n
Shows which failures cost the most production time<\/td>\n
Start and end captured automatically at the machine, reason assigned by the operator<\/td>\n
Maintenance and shift lead, daily<\/td>\n<\/tr>\n
\n
Micro-stops (count and total)<\/td>\n
Makes visible losses that never appear in a work order<\/td>\n
Automatically, including stops of a few seconds<\/td>\n
Maintenance and methods, weekly<\/td>\n<\/tr>\n
\n
Availability<\/td>\n
Sums up how much of the planned time the machine actually ran<\/td>\n
Run time divided by planned production time<\/td>\n
Plant management and maintenance, weekly<\/td>\n<\/tr>\n
\n
MTBF<\/td>\n
Shows how often a machine fails<\/td>\n
Run time divided by the number of technical failures<\/td>\n
Maintenance manager, monthly<\/td>\n<\/tr>\n
\n
MTTR<\/td>\n
Shows how long it takes to get it running again<\/td>\n
Total failure duration divided by the number of failures<\/td>\n
Maintenance manager, monthly<\/td>\n<\/tr>\n
\n
Recurring failures (top 5)<\/td>\n
Sets the order of actions<\/td>\n
Pareto of downtime reasons per machine<\/td>\n
Maintenance and improvement team, weekly<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The key is separating reasons. A stop caused by missing material or missing staff is not a machine failure and does not belong in MTBF or MTTR. It still belongs on the dashboard, or it will be mistaken for a technical failure. The machine’s OEE remains the shared metric that connects these losses to output.<\/p>\n<\/figure>\n
MTBF and MTTR from timestamps, not from memory<\/h2>\n
MTBF and MTTR appear in almost every maintenance plan. In practice they are often calculated from failure reports entered by hand and late. MTTR then measures the time until the report, not until restart, and short failures go missing altogether. With automatically captured timestamps, the method looks like this:<\/p>\n
\n
Record the start and end of every stop at the machine.<\/strong> Not in the shift log, but where the machine actually stops and restarts.<\/li>\n
Assign a reason to every longer stop.<\/strong> A short list of around ten reasons is enough, grouped into technical, organisational and material.<\/li>\n
Use only technical failures for MTBF and MTTR.<\/strong> Changeovers, breaks and material shortages stay separate.<\/li>\n
Count micro-stops separately.<\/strong> They distort MTBF if included and disappear if ignored.<\/li>\n
Calculate per machine and per month.<\/strong> For example, a machine with four technical failures in 160 hours of run time has an MTBF of 40 hours; this example is only an illustration.<\/li>\n<\/ol>\n
The result is a set of metrics that maintenance and production both trust, because both teams see the same timestamps.<\/p>\n
What to leave off<\/h2>\n
A maintenance dashboard does not get better by showing more. These items usually cost more attention than they return in decisions:<\/p>\n
\n
Plant-wide averages.<\/strong> A plant MTBF hides the two machines that are really causing trouble.<\/li>\n
Stops without a reason.<\/strong> A large “Other” category means the reason list or the way reasons are entered needs fixing.<\/li>\n
Real-time curves for everyone.<\/strong> Live data helps at the line; in a monthly review, the trend is enough.<\/li>\n
Metrics without an owner.<\/strong> A number nobody looks at and nobody acts on belongs in a report, not on the dashboard.<\/li>\n<\/ul>\n
Who looks at what, and when<\/h2>\n
A dashboard only has an effect when it is clear who looks at which number and how often:<\/p>\n
\n
Daily, shift lead and maintenance:<\/strong> the last 24 hours of downtime with duration and reason, open failures, micro-stops on critical machines.<\/li>\n
Weekly, maintenance and improvement team:<\/strong> top 5 downtime reasons, availability per machine, actions and their status.<\/li>\n
Monthly, maintenance manager and plant management:<\/strong> MTBF and MTTR per machine as a trend, effect of actions, priorities for next month.<\/li>\n<\/ul>\n
TEEPTRAK measures OEE, downtime and micro-stops in real time on every machine. A module is wired into the electrical cabinet and a sensor sits at the line; installation takes about one hour per machine, with no PLC connection, and OEE is available within 48 hours. The timestamps and downtime reasons can then serve as a data source for a maintenance dashboard. TEEPTRAK is not an MES and is used in more than 700 plants in over 30 countries.<\/p>\n
![\"Four](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/11\/teeptrak-wartungs-dashboard-en.png\")
<\/figure>\n