A maintenance KPI dashboard is a single screen that tells a maintenance team whether reliability and cost are under control. The good ones are laid out so leading discipline metrics sit on top for weekly action and lagging outcomes sit below for monthly review, every tile shows direction and not just a number, and each refreshes on the cadence its metric is actually managed.
This is a design guide, not a metric list. For which numbers to track and how to compute them, start with maintenance KPIs: the 10 that matter. Here the question is different: given those metrics, how do you arrange them on one screen so a crew reads the right thing at the right moment and acts on it? Most maintenance dashboards fail not because they picked the wrong metrics but because they dumped forty of them onto a screen nobody reads. Layout is the job.
What should a maintenance KPI dashboard show?
It should show a small set of metrics organized by what the reader does with them. The core principle is that a dashboard is a decision surface, not a data warehouse: every tile has to earn its place by driving an action or answering a standing question. A useful maintenance dashboard carries three kinds of tile, leading discipline metrics you act on weekly, lagging reliability outcomes you review monthly, and cost normalized so it can be compared. If a tile does not change anyone's behavior, it belongs in a report, not on the dashboard.
How should the dashboard be laid out?
Top to bottom, in order of how often you act: leading discipline first, reliability outcomes second, money third. The reason is behavioral. Whatever sits at the top of the screen is what the morning meeting looks at, so the top band should hold the metrics a crew can change this week, PM compliance, schedule compliance, planned work percentage, ready backlog, emergency work percentage. The middle band holds the lagging trends those behaviors produce over months: MTBF MTTR unplanned downtime. The bottom band holds cost: cost per unit and a top-offenders list ranking assets by failures times downtime cost. That reading order, discipline, then outcome, then dollars, mirrors cause and effect, and it keeps the daily standup arguing about the things it can actually move.
What does a good tile look like?
A single number is almost useless; a tile needs four things to drive a decision: the current value, its direction versus last period, its target or healthy range, and a status color for exceptions. Direction matters most, a plant at 88% PM compliance and climbing is in a very different place from one at 88% and falling, and the bare number hides that. Reserve color for exceptions only. If every tile is red, amber, or green, color stops meaning anything; use the plant's rust accent for the one or two tiles that need attention this week and leave the rest neutral.
How often should each tile refresh?
Match the refresh to the decision. Leading discipline metrics belong to the weekly planning and scheduling rhythm, so they refresh weekly and are reviewed in the schedule meeting. Reliability outcomes move slowly and are noisy week to week, so they refresh monthly. Cost rolls to a trailing twelve months and updates monthly. The one exception is unplanned downtime, which is worth showing near-live where machine data allows, because a line down right now is a today problem, not a month-end one. A dashboard that refreshes everything nightly trains people to react to noise; a dashboard that matches cadence to decision trains them to act at the right altitude.
Floor-facing or manager-facing, which dashboard?
You usually need two views of the same data. The floor-facing view is big, glanceable, and short: a wall screen showing this week's discipline tiles and today's downtime, readable from across the shop. The manager-facing view is deeper: trends, per-asset breakdowns, the top-offenders list, and drill-downs into work orders. Build them from one data layer so the numbers always agree, the fastest way to destroy trust in a dashboard is to have the wall screen and the manager's report disagree by month-end. Same source, two lenses.
Keep the two views deliberately different in density. The floor screen should survive a three-second glance from twenty feet, which means large type, few tiles, and no fine print; a technician walking past should be able to tell if the week is on track without stopping. The manager view can be dense because it is read sitting down, so that is where the per-asset tables, drill-downs, and annotations live. Trying to serve both audiences with one busy screen satisfies neither, the floor cannot read it and the manager cannot analyze from it.
How do you build one people actually use?
Start smaller than you want to and grow with data quality. A beautiful dashboard built on numbers nobody trusts teaches the whole plant to ignore dashboards, so the build order is a trust-building exercise as much as a design one.
- Start with four metrics you can compute from trusted data. Usually PM compliance, ready backlog, unplanned downtime, and cost. Ship those four before adding anything harder to measure.
- Add trend to every tile before adding more tiles. Direction on four metrics beats a snapshot of twelve. Depth of read beats breadth of coverage.
- Layer in the lagging band once history exists. MTBF and MTTR need a few months of clean failure data to mean anything. Add them when the history is real, not on day one.
- Unify the sources behind one layer. Work orders, downtime, and cost usually live in three systems. Join them once so the floor and manager views cannot disagree.
- Put the dashboard in the standup, not just on a wall. A dashboard reviewed on a rhythm changes behavior; a dashboard nobody discusses is wallpaper. Assign each red tile an owner and an action.
| Band | Tiles | Refresh | Reviewed in |
|---|---|---|---|
| Leading (top) | PM & schedule compliance, planned %, backlog, emergency % | Weekly | Weekly schedule meeting |
| Lagging (middle) | MTBF, MTTR, unplanned downtime | Monthly (downtime near-live) | Monthly reliability review |
| Money (bottom) | Cost per unit, cost % of RAV, top offenders | Monthly, trailing 12 | Monthly with finance |
What are the most common dashboard mistakes?
The failure modes are predictable, and every one of them is a design choice rather than a metric problem. The first is too many tiles. A screen with forty numbers has no hierarchy, so the eye lands nowhere and the standup drifts. Cutting to ten forces the team to decide what actually drives decisions. The second is numbers with no direction: a wall of bare values tells you where you are but not where you are going, and direction is what turns a metric into a warning. The third is color inflation when every tile is green, amber, or red, the palette stops carrying information and people tune it out. Reserve the rust accent for the one or two exceptions that need attention this week.
The fourth mistake is a mismatch between refresh and decision. A dashboard that repaints every metric overnight teaches the crew to react to random weekly noise in slow-moving lagging metrics, which produces thrash instead of improvement. The fifth, and the most corrosive, is disagreeing sources: when the wall screen pulls downtime from one system and the monthly report pulls it from another, the two disagree by month-end, and the moment people catch a dashboard being wrong they stop believing all of it. Trust is the whole asset; one visible contradiction spends it.
There is also a quieter failure: a dashboard that is technically perfect but never enters a meeting. A screen nobody discusses changes no behavior. The dashboards that move plants are the ones wired into the weekly schedule review and the monthly reliability review, where each off-target tile gets an owner and a next action before anyone leaves the room. The layout supports the ritual; the ritual is what actually moves backlog and lifts MTBF. Treat the dashboard as the agenda for a standing meeting, not as decoration for a hallway, and it starts to earn its screen.
Where do the data and definitions come from?
The plumbing behind the layout is the hard part. Work orders live in a CMMS, downtime in an MES or historian, and cost in the finance ledger, and a dashboard is only as honest as the join between them. Building that unified layer with live tiles is the work described on our platform overview; the CLS case study shows automated daily reporting replacing spreadsheets built by hand every morning. For the metric definitions behind each tile, lean on standards, not vendor numbers.
- The Society for Maintenance and Reliability Professionals (SMRP) publishes formal definitions for the metrics on this dashboard, PM compliance, schedule compliance, planned and ready backlog, and cost metrics, in its Best Practices library (SMRP Best Practices, Metrics & Guidelines). Standardize your tile definitions on SMRP so benchmarking means something.
- The payoff for acting on the leading band is documented by U.S. Department of Energy FEMP guidance maintained by PNNL: shifting from reactive toward planned and condition-based maintenance offers savings that can exceed 30–40% with predictive adding 8–12% over preventive-only (PNNL, O&M Best Practices: Maintenance Approaches).
Pick a small set of metrics, arrange them by action cadence, give every tile a direction, and review the screen on a rhythm. That discipline, not the chart library, is what turns a dashboard from decoration into a management tool. For the downtime and capacity side, our OEE calculator connects lost time to output, and the whole system starts at the equipment reliability hub.