Maintenance KPIs and Dashboards: What to Review Weekly

Published on 10/21/2026 • Updated on 10/23/2026

Every Monday at 9 AM, the plant head asks the same question: "How was maintenance last week?" And every Monday, the maintenance head gives the same answer: "Busy." It is a true answer and a useless one. Busy is not a number; it does not trend, it does not compare, and it does not tell the plant head whether the factory is getting more reliable or slowly falling apart behind a wall of activity. The plant that answers "busy" and the plant that answers "breakdown hours down 18 percent this quarter, PM compliance at 94, two repeat offenders on the packaging line" are running the same equipment. One of them is managing it.

Maintenance KPIs are not a reporting exercise; they are the steering wheel. This guide covers the handful of metrics that actually steer a plant (and the vanity metrics that do not), how to compute MTTR and MTBF without a statistics degree, what a weekly dashboard review should look like, and how to start when your data currently lives in a register book. It extends our MTTR and MTBF worked examples and our CMMS explainer.

The metrics that steer

Notice what is absent: work orders closed per technician (rewards speed over quality and invites pencil-whipping), and total work orders raised (rewards failure). A metric that can be gamed will be gamed; the five above resist gaming because each is anchored to the machine, not the person.

MTTR and MTBF in plain arithmetic

MTTR (mean time to repair) is total repair hours divided by number of repairs. If the compressors took 14, 9, 22 and 11 hours across four failures last quarter, MTTR is 14 hours. It measures how fast you fix. MTBF (mean time between failures) is total running time divided by number of failures. If a line ran 1,800 hours and failed 6 times, MTBF is 300 hours. It measures how often it breaks. The two move independently and tell you different stories: MTBF falling with stable MTTR means the machine is degrading (investigate causes); MTTR rising with stable MTBF means your response is degrading (spares, skills, diagnosis).

The worked examples post runs these numbers in detail. The discipline that matters here is simpler: compute both per critical asset monthly, and require that any movement gets a sentence of explanation in the review. A number with a reason is information; a number without one is decoration. Write the sentence down; next quarter's reviewer will thank you. And never average across asset classes: a plant-wide MTTR mixes the lift with the CNC and means nothing.

The weekly dashboard review

The review that works is fifteen minutes, same time weekly, same five numbers, and ends with owners and dates rather than observations. The agenda: breakdown hours versus last week and versus the quarter's trend; PM compliance with the overdue list named; backlog and oldest ticket; the repeat-failure list (the root-cause agenda); and one sentence each on any MTTR or MTBF that moved. When the dashboard shows it, nobody argues about what happened, and the meeting spends its minutes on what to do.

Two rules make it stick. The plant head attends, because a review the boss skips is a review the plant stops preparing. And every action lands as a work order or a dated owner before the meeting ends, because "noted" is where maintenance improvement goes to die. Within a quarter, the review changes the team's relationship with its own numbers: people start closing the loop before the meeting, because the dashboard is going to say it anyway.

Starting from a register book

If today's data is a breakdown register and a PM diary, you are closer than you think. The register's rows are work orders waiting to be structured: asset, reported time, repair start, closure, cause, spares. Moving to software is not a data-entry project; it is the same entries typed into a form that computes the KPIs as a by-product. The dashboard's first month will be ugly (that is the baseline doing its job), the second month will show the first trend, and the third month is when the review starts making decisions the register never could.

The one field to add immediately, even before any software: repair start time alongside reported and closed. Without it, MTTR is unknowable and response time is invisible, and both are the numbers the plant head will ask for first. Our breakdown maintenance log guide covers the full field set; the dashboard is only ever as good as the log underneath it.

The first-quarter arc

Expect the same three phases every plant goes through. Month one, the numbers get worse on paper: downtime is finally counted honestly, the overdue PM list is longer than anyone claimed, and the backlog has a number for the first time. This is not deterioration; it is vision. Month two, the easy wins land: the overdue list clears, the worst repeat offender gets a real root-cause fix, and the review stops being an argument about facts. Month three, the trend lines bend, and the conversation shifts from "are we getting better" to "which constraint do we attack next".

The plant head's job through the arc is to protect the metric when it is unflattering. The team that gets scolded for an honest bad number will produce a dishonest good one within a month, and then the dashboard is decoration again. Thank the bad number; it is the only kind that tells you where to dig.

Reader Q&A

Bottom line

This week, answer the Monday question with one number: count last week's breakdown hours from the register. That single figure, produced weekly, is already a better dashboard than "busy", and it costs ten minutes.

This quarter, structure the log so the five KPIs compute themselves, and start the fifteen-minute review with the plant head in the room. The plant that measures does not just fix faster; it eventually stops needing to, which is the only KPI that was ever the point.