How to Build a Production Downtime Dashboard in Power BI

The most common production downtime dashboard is a big number: total downtime hours this week, maybe trended. It looks like management information and it changes nothing, because it does not answer the only question that leads to action — what, specifically, should we fix first.

A plant does not reduce downtime by knowing it lost 240 hours. It reduces downtime by knowing that 60 of those hours were one changeover problem on Line 3, that the problem is trending worse, and that it costs more per hour than the larger but cheaper category above it. The total hides all of that.

A downtime dashboard earns its place only if it turns lost time into a ranked, specific list of what to fix. That is a design decision, and it starts with the data model.

The foundation is a downtime event table: one row per stoppage, with the line or asset, start and end time (so duration is derived, not typed), and a reason code. Around it sit dimensions — the asset hierarchy (plant, line, machine), a calendar and shift dimension, and, most importantly, a governed reason-code taxonomy.

The reason codes are where downtime dashboards live or die. If operators can free-type the reason, you get "broken," "issue," and forty spellings of "changeover," and no Pareto is possible. A controlled, hierarchical reason taxonomy — category (mechanical, changeover, material, quality), then specific cause — is what makes the data analysable. Getting that taxonomy right, and enforced at capture, is more than half the work.

Attach a cost dimension where you can — a cost-per-hour by line, or lost-units times margin — so downtime can be ranked by money, not just minutes. The most expensive hour and the longest hour are often not the same, and money is the ranking that gets attention.

The headline visual should be a Pareto: downtime reasons ranked by total duration or, better, total cost, descending, with the cumulative line. This is the visual that makes the vital few obvious — the two or three reasons driving most of the loss — and directs attention to them instead of spreading it across everything.

Make it drillable: from the plant Pareto to a line, from a line to a specific reason, from a reason to the individual events behind it with their timestamps. A leader should be able to go from "changeover is our biggest loss" to "here are the twelve changeover stoppages last week and when they happened" in two clicks, because that is where the fix conversation actually starts.

Everything else on the dashboard supports the Pareto: a trend of the top reasons over time, a breakdown by line and shift, and the events detail. But the Pareto is the point — it converts a pile of stoppages into a ranked list of what to attack.

Two distinctions turn a descriptive dashboard into a diagnostic one. First, split planned downtime (scheduled maintenance, planned changeovers) from unplanned (breakdowns, faults). They are managed completely differently, and mixing them makes both invisible — a plant with high planned downtime and low unplanned is in a very different position from the reverse, and the total cannot tell them apart.

Second, for unplanned downtime, distinguish frequency from recovery with two measures: mean time between failures (MTBF) and mean time to repair (MTTR). A line with a low MTBF fails often; a line with a high MTTR takes a long time to come back. The fix is different — reliability engineering for the first, spares and response for the second — and a single "downtime hours" number cannot tell you which problem you have.

With these, the dashboard stops describing downtime and starts diagnosing it: is this a planned-load problem, a things-break-too-often problem, or a we-are-too-slow-to-fix-it problem. Those are three different action plans.

A downtime dashboard fed by a paper log keyed in the next morning is always describing the past, and it inherits the errors of manual entry. The version that changes behaviour reads from the MES or machine data directly, so a stoppage appears while the shift is still running and the reason can be captured at the machine rather than reconstructed later.

On a Microsoft estate, the pattern is to stream MES and machine data into OneLake — through Fabric Eventstream for real-time signals or a pipeline for batch — model the downtime events in the gold layer, and read them in Power BI on Direct Lake so the dashboard reflects the line as it runs. Fabric's real-time capabilities can also raise an alert when a line goes down or a reason crosses a threshold, so the dashboard is backed by a signal that reaches someone, not just a chart someone might open.

Live data also improves the reason quality: capturing the reason at the moment of the stoppage, at the machine, is far more accurate than a supervisor guessing at it the next day. Better data in makes the Pareto trustworthy.

A production downtime dashboard drives action when it does four things: models events against a governed reason-code taxonomy; leads with a Pareto of reasons by cost, drillable to the events; separates planned from unplanned and frequency (MTBF) from recovery (MTTR); and runs on live MES data rather than a morning-after log. Total lost hours is the metric to bury, not to headline.

Built this way, the dashboard answers the question that reduces downtime — what few things, on which lines, are costing the most, and is our fix working — and it answers it during the shift, not at the monthly review.

The technology is Power BI on a governed Microsoft Fabric foundation. The value is the design: a dashboard that ranks and diagnoses rather than one that totals. Optimise for the fix conversation, and the number comes down.