What are maintenance KPIs?

A maintenance KPI is a work order metric that measures how fast and how proactively a team keeps equipment running. The useful ones come from data the team already records: when a request came in, when work started, when it closed, and whether the job was planned or reactive. A key performance indicator only earns its place when someone changes a decision because of it.

That is the line most KPI guides miss. They list 15 metrics and call it a day. The reliability consultancy IDCON puts it plainly in its maintenance KPI guidance: a maintenance KPI is only useful if a decision changes because of it. So track the small set that moves a regional manager to act, and ignore the vanity numbers that just look busy.

The vanity traps to name and skip:

• Work orders closed. Easy to game by closing small jobs while the real problems sit open, per oxmaint's maintenance KPI guidance.
• Total labor hours. Hours without output context tell you nothing about whether the right work got done.
• Number of PMs scheduled. That measures the size of the schedule, not whether the preventive maintenance actually got completed.
• Wrench time during firefighting. High wrench time on unplanned reactive repairs is not efficiency. It is a team running flat out to keep up.

What this looks like on the ground depends on your vertical. In a QSR it is the broken fryer, the walk-in compressor, the overdue hood cleaning. In a C-store it is the forecourt pump that goes down at 11pm and the cooler compressor at a rural stop where nobody logged what actually broke. In a hotel it is guest-room AC, rooftop HVAC on a PPM schedule, and the maintenance request a housekeeper raises mid-turn. The track-the-four-that-matter discipline holds across all of them.

Workflow diagram, submission to resolution

Every maintenance KPI starts and stops on a work order timestamp, so the workflow is where the numbers come from. The flow runs from submission to closure in five steps, and each metric's clock starts or stops at a specific point in that flow. Get the workflow clean and the metrics calculate themselves.

Here is the submission-to-resolution flow at the level a closing attendant or area maintenance tech would read it:

1. Submit. Store staff or a third-party vendor scans a QR code on the asset and opens a work request. The form auto-populates the asset, location, and category. This is the submission timestamp, the start of request age.
2. Triage and approve. A manager reviews the request in the Xenia app, sets a severity level (low, medium, high, or critical), and confirms it is real. This is where the job gets tagged planned or reactive.
3. Assign and route. The work order auto-routes by location and priority to the right tech or vendor. This is the assignment timestamp.
4. Repair. The tech starts the fix. This is the repair-start timestamp, the start of the MTTR clock.
5. Resolve and close. Work is verified complete and the order closes with notes and a photo. The close timestamp stops the MTTR clock and clears the item from backlog.

Where each metric's clock sits on the flow:

• MTTR runs from repair start (step 4) to close (step 5). It is hands-on repair time only, per MaintainX's mean time to repair guide and Fiix's MTTR breakdown.
• Backlog is everything submitted at step 1 but not yet closed at step 5.
• Planned vs reactive is decided at step 2. A scheduled PM counts as planned. A breakdown request counts as reactive.

A quick honesty note on the submission step. Store staff and outside vendors submit work requests by QR code without logging in. Approval, assignment, and routing happen inside the authenticated app, so a manager always owns the triage. For a deeper walk through the routing rules, the dispatch-to-resolution workflow guide covers how priority and skill drive the assignment. The point here is simpler: no clean submission and close, no clean metric.

The core work order metrics: MTTR, backlog, PMP, and planned-vs-reactive

The four metrics that change maintenance decisions are MTTR, work order backlog, PMP, and the planned-vs-reactive ratio, with on-time PM completion as the close fifth. Each has a simple formula and a healthy benchmark. Here they are side by side, then a short read on each.

| Metric | What it answers | Formula | Healthy benchmark | Source |
|---|---|---|---|---|
| Mean time to repair (MTTR) | How fast do we fix it once work starts? | Total repair time / number of repairs | Under 4-5 hours for critical equipment | MaintainX, Limble |
| Work order backlog | Is work piling up faster than we close it? | Backlog hours / weekly maintenance capacity, in weeks | 3-5 weeks (some sources 4-6). Over 8 = work not closing, under 2 = no runway | Limble, oxmaint |
| Planned maintenance percentage (PMP) | How much of our work is proactive? | (Planned maintenance hours / total maintenance hours) x 100 | 80% good, 85-90% excellent, 90-95% world-class | MaintainX, UpKeep |
| Planned-vs-reactive ratio | Are we firefighting? | Planned hours to reactive hours | 80:20 target. Average shop sits 50-60% planned | Limble, MaintainX |
| On-time PM completion | Are scheduled PMs actually done on time? | (PMs completed on time / PMs scheduled) x 100 | 90% or higher | Limble |

MTTR. Mean time to repair is total hands-on repair time divided by the number of repairs. Worked example: 25 repair-hours across 5 repair events is a 5-hour MTTR. MaintainX notes that the best maintenance teams run under five hours, and an MTTR under 4 hours is the world-class mark for critical equipment. MTTR counts hands-on repair time only. It does not include detection delay or waiting for parts. Pair it with mean time between failure for the full availability picture (availability = MTBF / (MTBF + MTTR)).

Backlog. Work order backlog is the volume of approved-but-unclosed work, usually expressed in weeks of capacity. The healthy range is 3-5 weeks, with oxmaint citing a 4-6 week target. Over about 8 weeks means work is not closing. Under about 2 weeks means there is no planning runway and your team is reacting to whatever lands next. The multi-site twist matters here: watch backlog per location, not just the portfolio total. One site sitting at 9 weeks hides easily inside a 4-week average.

PMP. Planned maintenance percentage is planned maintenance hours divided by total maintenance hours, times 100. MaintainX's published tiers put 80% at good, 85-90% at excellent, and 90-95% at world-class. UpKeep frames 85% and up as world-class. Most multi-site frontline operators start lower. A realistic floor is 70%, then you climb toward the world-class ceiling over time.

Planned vs reactive. This is PMP's close sibling. The target split is 80:20, meaning 80% planned and 20% reactive. The reality gap is the story. Limble's planned vs unplanned ratio data shows the average maintenance department sits at 50-60% planned, still spending almost half its time firefighting. PMP measures the mix of work. On-time PM completion measures execution. A site can run 85% planned and still blow its PM due dates.

On-time PM completion. This is PMs completed on time divided by PMs scheduled, times 100, with a 90% target. It is the metric a multi-site operator can move fastest, because it is a scheduling-and-accountability discipline, not a capital problem. Most KPI sources benchmark for plants and factories. For frontline ops the realistic win is often just getting from "everything is reactive and undocumented" to a measured planned-vs-reactive ratio in the first place. Limble's maintenance KPI guide covers the formulas in depth.

How does Xenia's approach differ from a full CMMS?

Xenia is not a full CMMS. It is the frontline submission and closure layer that produces clean work order data, then rolls those metrics up by location and region without a separate BI module. Deep asset-cost, depreciation, and parts-inventory analytics still live in a full computerized maintenance management system like Limble or Service Channel. Being honest about that line is what makes the rest of this credible.

Here is the scope split, frontline metrics layer versus full CMMS depth:

| Capability | Xenia (frontline ops layer) | Full CMMS (Limble, Service Channel, eMaint) |
|---|---|---|
| No-login QR work request submission | Yes, a defensible differentiator | Typically requires a seat or license for submitters |
| MTTR, backlog, PMP, on-time PM rollup by location and region | Yes, from closed work order data, no separate BI tool | Yes, often through a reporting or BI module |
| Parts inventory and reorder | No | Yes |
| Depreciation and asset lifecycle cost | No | Yes |
| Vendor invoicing depth | No | Yes |
| Audits, daily ops, and comms in the same app | Yes | No |

Where the full CMMS still leads, it leads clearly. MaintainX's reporting auto-logs who did the work, how long it took, and which parts and assets were involved, the asset-cost depth Xenia does not claim. Per Tractian's CMMS roundup, eMaint leans heavily on performance measurement with custom KPI dashboards, and Tractian itself is sensor and predictive-monitoring heavy. None of that is a knock. It is a different job.

The honest multi-site story is that some operators run both. Refuel uses Xenia for frontline ops and kept Service Channel for asset depth. Refuel's switching drivers were offline mode for rural fuel stops, the QR work order workflow, and that retained third-party Service Channel integration. Xenia is the frontline submission, closure, and rollup layer. Service Channel keeps the deep asset and vendor-invoicing record. Xenia gives store staff and outside vendors a no-login QR work request that auto-populates asset, location, and category, then a manager approves and routes it. That is the entry point no full CMMS matches without handing every submitter a seat.

Where do operators see results?

Operators see results when the maintenance numbers stop living in a spreadsheet and start rolling up by location, so a regional manager can see which site's backlog is blowing out before it becomes a downtime event. The payoff is not the dashboard. It is a manager looking at four numbers and knowing which location needs a visit this week before the equipment fails on a Friday night.

The proof shows up as speed of execution at real multi-site operators:

• Power Market runs Xenia live across 360 C-store locations with bilingual checklists and QR deployment, and reported 40% faster task resolution. Faster task resolution is the operator-facing flavor of lower MTTR: the work order closes sooner, so the clock stops sooner.
• Mezeh cut manager phone calls by 60% after putting QR submission on the assets that break. That is the frontline-accountability proof. The 11pm call about a broken walk-in becomes a tagged work order with a photo, not a voicemail.
• Refuel runs the complementary setup, Xenia for frontline ops plus Service Channel for asset depth, which is the honest multi-site facilities story rather than a rip-and-replace pitch.

The stakes are real even if the headline numbers come from heavy industry. A 2025 Censuswide survey for Fluke Corporation of more than 600 senior maintenance decision-makers found unplanned downtime costs manufacturers up to $852 million per week, with 61% hit by unplanned downtime in the past year, per the study release. That figure is a factory number, not a QSR or C-store number. But a dead walk-in at one restaurant or a downed pump at one fuel stop is the same problem in miniature. The metric that catches it early is backlog by location, paired with a high planned-vs-reactive ratio.

That is also where the issues-first dashboard earns its keep. It surfaces what is forming, the site whose backlog is climbing, not just whether yesterday's tasks got done. Custom dashboards in Xenia are configurable operations views, not Looker-grade BI, and the Analytical Agent is scoped to your operations data inside Xenia. That is the point. A regional manager reads four numbers and knows where to drive this week.

How to track maintenance KPIs in Xenia

You track maintenance KPIs in Xenia by capturing clean work order data at submission and closure, then letting the dashboard compute MTTR, backlog, PMP, and planned-vs-reactive automatically by location and region. There is no separate BI tool to license. The whole approach rests on tagging the work order correctly the moment it is created.

1. Put QR codes on the assets that fail. Fryers, walk-in compressors, pumps, coolers, rooftop HVAC, ice machines. Scanning auto-populates asset, location, and category, so every work order is tagged correctly from the first second. Clean tagging is what makes per-asset and per-location MTTR possible later.
2. Set tiered severity levels. Low, medium, high, critical. Severity drives routing and lets you compute MTTR for critical equipment separately from cosmetic fixes.
3. Tag planned vs reactive at approval. Scheduled PMs created on a cadence count as planned. QR-submitted breakdowns count as reactive. This single field is what makes PMP and the planned-vs-reactive ratio calculable without manual sorting.
4. Auto-assign by location. Work routes to the right tech or vendor automatically, which keeps the assignment-to-repair gap short and honest.
5. Close with proof. Work orders close with notes and a photo. The close timestamp stops the MTTR clock and clears the item from backlog. No close, no metric.
6. Read the rollup. The dashboard surfaces MTTR, backlog in weeks, PMP, and on-time PM completion by location, district, and region. The Analytical Agent answers plain-language questions like "Which region has the longest open work order backlog this month?" against the same data, with no SQL and no BI license.

The planned side of that ratio does not appear by accident. Scheduling PMs on a cadence is what creates planned work in the first place, so a standing maintenance calendar is the on-ramp. The preventive maintenance schedule guide and the phases of planned maintenance walk through how to build that cadence, and maintenance work order software covers the submission side. Get those running and the four metrics stop being a spreadsheet chore.