Downtime Cost, OEE & Analytics
What did downtime cost — in money?
Every plant we talk to can tell you how many hours a machine was down last month. Almost none can tell you what that downtime actually cost, or which of forty assets is quietly bleeding the most money. Downtime hours sitting in a work-order log don't tell a plant head where to spend the next capital rupee — a rupee figure, ranked, does. That's the gap this screen closes, and it does it from the work orders you're already logging, provided you keep two asset fields current.
What you get on one screen
This is a rolling KPI view over your work orders, computed for a window you pick — 30, 90, 180 or 365 days, defaulting to 90. Every tile refreshes to that window except two trends that always look further back regardless of what you've selected.
- Availability, MTTR, MTBF, PM compliance
- Open backlog, and backlog older than 14 days
- Total work-order cost, labour hours, failure count
- Total downtime hours and downtime cost in ₹
- Active assets, spares at or below reorder level, open breakdowns
If you've read up on OEE or TPM before, you'll recognise some of this framing — the OEE explained page covers the classic three-factor model this screen also uses per asset. What's different here is the money layer sitting on top of the hours, which is the part most CMMS dashboards skip.
Downtime cost, ranked
Hours of downtime are not equal across a fleet. An hour on a bottleneck press costs a plant far more than an hour on a standby compressor, but a plain downtime-hours report treats them the same. This screen doesn't. For every asset, downtime cost is downtime hours multiplied by that asset's downtime cost per hour, and the top 8 assets by cost are shown as a Pareto — so you see in one glance where the rupees are actually going, not just where the hours are. Where rated output per hour is filled in for an asset, the same view estimates units lost, so a maintenance head can walk into a review with "this pump cost us ₹X and Y units" instead of "this pump was down for six hours."
The catch, and we'd rather you know it now: this entire section is only as good as two manually maintained fields — downtime cost per hour and rated output per hour — sitting on the asset record. Leave them blank and the ranking simply has nothing to rank. This is why the feature works best in plants with a defined set of costed bottleneck machines, not across a few hundred loosely tracked assets where nobody has the appetite to keep those fields current.
OEE per asset, sorted worst first
For assets with a production log, the screen computes full OEE — availability × performance × quality — and sorts assets worst first, so the machine dragging your line the hardest is the one you see at the top, not buried in row 40 of a spreadsheet. Assets without a production log are skipped rather than shown with a misleading zero, and performance shows as null when rated output isn't set, rather than guessing.
Be clear about what this is not: it's a plant-level OEE per asset, not a shift-level or line-level breakdown, and it doesn't model the six classic big-loss categories that a full TPM programme tracks. If your OEE initiative needs shift-by-shift loss attribution, or your line requires the OEE framework in its complete form, this screen gives you a useful proxy, not that programme.
Where the downtime is actually going
Two more views exist to answer "why," not just "how much." The failure-mode Pareto groups unplanned work orders by failure mode and shows the top 8 by downtime hours, with an explicit "uncoded" bucket — which, honestly, is often the largest bar in the first few months, and that's fine; it tells you where your technicians need better prompts at work-order creation, not a data problem to hide.
Downtime segmentation goes a layer deeper, splitting the average minutes per resolved breakdown into:
- Approval wait
- Response wait
- Repair
- Inspection and closure
- Parts wait
In an Indian plant, this segmentation earns its keep fast. A breakdown that "took four hours" might really be forty minutes of repair and three hours of parts wait because the spare was two days out on lead time, or an hour of approval wait because the shift supervisor was on the floor and not near a terminal. Segmenting the wait tells you whether to fix your spares stocking, your approval chain, or your technician's actual repair skill — three very different fixes that a single MTTR number hides.
The numbers behind the numbers
A few mechanics are worth knowing so the figures don't surprise you:
- Availability here is fleet-wide, not per-asset: (fleet hours − downtime) / fleet hours, where fleet hours = asset count × days × 24. It answers "how much of our total calendar capacity did we lose," not "how available was machine 7."
- MTTR is total downtime divided by work orders that actually have a downtime window; MTBF is (fleet hours − downtime) divided by breakdown and corrective count.
- PM compliance counts a PM done on or before its scheduled date as on time; a PM with no scheduled date is counted as on time by default.
- Backlog counts every open work order regardless of age — it isn't confined to your selected window, so it won't shrink just because you switch from 90 days to 30.
- Everything is attributed by the work order's creation date falling in the window, not by when the downtime actually happened, which matters if your team logs a breakdown a day or two after it occurs.
None of this needs a new process — it runs on the work orders and asset records you're already keeping inside the CMMS.
What this screen won't do for you
We'd rather tell you now than have you find out after go-live. There's no export from this screen — no CSV, PDF or print — and no scheduled or emailed report, no BI connector. The only outbound paths are a tenant-wide ZIP-of-CSVs export elsewhere in the product, and a read-only REST API for teams who want to pull data into their own systems. There's also no custom report builder here — the metric set and the four window options are fixed, not configurable — and super admin accounts can't open this screen at all.
If your maintenance head needs the numbers to leave the tool on a schedule, or a shift-level OEE breakdown against the full TPM loss model, this page will frustrate you. If you're a plant with a handful of well-defined bottleneck assets where someone will actually keep cost-per-hour and rated output current, this is built for exactly that job. See how it sits against the rest of the system on features, check it against your own plant type on industries, or book a demo and we'll walk through your own work-order data on it.
Two fields decide whether the money numbers mean anything
Downtime cost and OEE quality on this screen depend entirely on two manually maintained asset fields — downtime cost per hour, and rated output per hour. If nobody owns updating these when a machine is de-bottlenecked, a die is changed, or a shift pattern shifts throughput, the Pareto ranking will still render, but it will rank last quarter's economics, not this quarter's. Assign one person — usually the maintenance planner, not IT — to review these two fields every time a capacity change or product-mix change happens on the floor. This is cheap to do for a handful of bottleneck assets; it becomes a real chore past thirty or forty costed machines, which is one reason AssetAI is built around a focused asset list rather than a plant-wide rollout.
Reading MTTR, MTBF and backlog without fooling yourself
A few things trip up first-time users of this screen:
- Attribution is by work-order creation date, not by when the downtime happened. A breakdown that occurred on day 89 but was logged as a work order on day 91 falls in the next window, not this one. Don't reconcile this screen against a shift log line by line — it won't match, by design.
- Backlog counts every open work order regardless of age, so it is not confined to whatever window you've picked. A 90-day view can still show a two-year-old open work order sitting in backlog.
- MTBF uses fleet hours, not per-asset run hours — a plant running two shifts and one on standby will show different MTBF math than a plant running three full shifts, even with identical failure counts. Read this alongside the OEE explained page if you're used to per-line uptime figures.
- Power cuts and grid instability, common on many Indian shop floors, will show up as downtime hours if they're logged as work orders — decide up front whether load-shedding gets its own failure-mode code or gets bucketed as "uncoded," because that decision changes your Pareto shape.
Where this genuinely does not fit
This screen was built for maintenance heads who already log downtime start and end and want that log turned into rupees, not for teams that need the numbers to leave the tool. There's no export, no scheduled email, and no BI connector on this screen — the only outbound path is the read-only REST API, and the only bulk export anywhere in the product is a tenant-wide CSV ZIP elsewhere. If your monthly review runs off a PowerPoint pulled from a BI dashboard, plan to pull the underlying data via API rather than expecting a print button here. Equally, if you're running a formal TPM programme that needs shift-level or line-level OEE and the six big-loss categories, this fixed metric set won't get you there — that's a deliberate scope limit, not an oversight. And super admin accounts can't open this screen at all, so make sure the plant head or maintenance head has the right role assigned before go-live, not after.
Downtime Cost, OEE & Analytics FAQs
How does AssetAI work out the rupee cost of downtime for each machine?
It calculates downtime cost in ₹ directly from the work orders you're already logging, then ranks assets by that figure rather than by raw hours. Each work order carries downtime hours against an asset; the screen multiplies that against the two asset-level cost fields you keep current, so the same hour of stoppage is priced differently on a bottleneck press versus a standby compressor. Nothing extra needs to be logged — it's the same data used for the OEE explained calculations, just with a money layer sitting on top of the hours. The result sits alongside total downtime hours on the same rolling KPI screen, so you can compare cost and hours side by side.
What asset fields do I need to keep updated for the downtime-cost numbers to be reliable?
The screen depends on two asset fields staying current — without them, the cost ranking is only as good as stale data lets it be. Downtime cost isn't a separate entry; it's derived by combining logged downtime hours from work orders with these two fields on each asset record, so if a field drifts out of date the ₹ figure for that asset drifts with it. This is why the page treats it as a data-hygiene requirement rather than a one-time setup. You can see how this fits alongside other tracked fields on the features page before deciding how much asset-master upkeep your team can commit to.
Should I look at 30-day or 90-day windows for my OEE and downtime KPIs?
It depends on what you're checking — the screen lets you pick 30, 90, 180 or 365 days, and defaults to 90. Every tile — availability, MTTR, MTBF, PM compliance, backlog, downtime cost — recalculates for whichever window you select, so a shorter window shows recent volatility while a longer one smooths it out. Two trend charts are the exception: they always look further back regardless of what window you've chosen, giving you a longer-run reference point even when you're zoomed into 30 days elsewhere. For a refresher on how the underlying availability/performance/quality math works, see the OEE explained page.
Why don't the two trend charts on the downtime dashboard change when I switch the date range?
They're designed to always look further back than whatever window you've selected, so they don't move with the 30/90/180/365-day filter the way the other tiles do. Every other tile — cost, MTTR, MTBF, PM compliance, backlog — refreshes to your chosen window, but the two trends exist to give you a longer-run reference regardless of the short-term view you're currently working in. This means you can drill into a 30-day window for recent firefighting while the trends still show the longer pattern behind it. It's a deliberate split between "what's happening now" and "what's the longer trajectory," both drawn from the same work orders you're already logging.
How does AssetAI calculate OEE per asset, and is it the standard model?
It uses the classic three-factor OEE model — availability, performance, quality — applied per asset rather than as a single plant-wide number. This runs on the same rolling KPI screen and the same work-order data used for downtime cost, so the same window (30, 90, 180 or 365 days) that recalculates MTTR and backlog also recalculates OEE. If you've read up on OEE or TPM before, the framing will be familiar; the OEE explained page walks through how each factor is derived. The addition here is that the ₹ downtime-cost figure sits next to the OEE tiles, so a low-OEE asset and its financial impact are visible on the same screen.
Can I see maintenance backlog and spare-parts risk alongside downtime cost on one screen?
Yes — open backlog, backlog older than 14 days, spares at or below reorder level, and open breakdowns are all tiles on the same rolling KPI screen as downtime cost and hours. All of them recalculate for the window you pick (30, 90, 180 or 365 days), so a spike in backlog or reorder-level spares shows up in the same timeframe as the cost and downtime figures, rather than in a separate report you have to reconcile manually. This is meant to give a plant head one place to check financial exposure, maintenance load, and stock risk together. The full tile list and how it's built is covered on the features page.
If a machine runs but produces rejected parts during downtime recovery, does AssetAI count that as uptime or loss?
AssetAI records machine running state separately from quality output. A machine in recovery mode shows as running time, not downtime. To capture quality losses, link your inspection/rejection data in asset work orders so rejection costs reflect in overall equipment effectiveness alongside availability metrics.
See Downtime Cost, OEE & Analytics on your own machines
A 30-minute demo on your plant, not our slides.