Key Points
- Price downtime per asset and count the full event, from failure through restart to stable output.
- Keep savings in separate buckets and strip out what monitoring can't fix, so finance can check every line.
- Lead with the conservative case, the break-even month, and an agreed way to verify results, since those are the numbers finance tends to approve. Ingredion’s published results, with $1.0M in production savings reported separately from $223K in maintenance savings, show what a clean result looks like.
Why is downtime so hard to justify to finance?
Every plant knows downtime hurts, but the trouble starts when finance asks for a number.
Over the past few months, we’ve talked with maintenance and reliability teams at more than 15 plants, and many of them tell us the same thing in different words: "We know it costs us, but we cannot quantify the business case." Lost output, emergency repairs, overtime, restart time, and stretched mechanics all get folded into one rough figure. When finance pushes back on that figure, the project stalls.
What wins approval is a more defensible number rather than a bigger one. This guide walks through six steps to calculate the real cost of downtime and turn it into a condition monitoring ROI case that finance can challenge and still approve.
In this guide:
- Define what stopped
- Measure the full disruption
- Separate the financial buckets
- Exclude what monitoring can't fix
- Model conservative scenarios
- Decide how you'll verify results
Step 1: What actually stopped?
A downtime cost is only as good as the scope behind it, so before you put a dollar figure on an hour, name what stopped.
One blended plant-wide rate is the most common mistake, and a machine-level stop and a front-end shutdown cost very different amounts. Therefore, using one average either overstates the small events or hides the big ones, and finance will spot it.
Do this: build your cost per hour at the level of the asset you plan to monitor. Start with bottlenecks and shared utilities, where an hour down is most likely to be an hour of lost sales.
Step 2: How long did the disruption really last?
The clock keeps running after the motor is replaced and only stops once the line is back at a stable rate.
Count the whole event:
- Stoppage: time from failure to the start of repair, including diagnosis and waiting for parts or a qualified mechanic.
- Repair: hands-on time to fix or replace.
- Restart: warm-up, changeover, cleaning, and quality checks before first good product.
- Ramp to stable output: reduced-rate running and extra scrap until the line is back to plan.
In one conversation Tractian had, a team included restart in a six-hour stoppage. In another, machines were down for three or four days because only one or two people could fix everything.
Customers also raised costs that come after the machine stops: product loss, idle staffing, overtime, schedule adherence, delivery, and demurrage.
Step 3: Which costs are cash, and which are estimates?
This is where most downtime calculations fall apart. Production value, repair spend, idle labor, and "hours avoided" get added into one savings number, and finance can't tell which parts are cash and which are estimates, so what do they do? They discount all of it.
Keep each bucket separate:
Use contribution margin instead of revenue. An hour of lost output is worth what the plant would have earned on it after variable costs, not the sales price.
Treat labor capacity honestly. Freeing skilled mechanics from emergency work is valuable, especially when they are hard to hire. But unless you avoid a hire or overtime, it is capacity, not cash. Label it that way and finance will trust the rest of the model more.
The formula, per event:
Cost per event = (lost units x contribution margin) + incremental expenses + scrap + repair cost difference
Step 4: Which downtime can condition monitoring actually prevent?
Some stopped hours never turn into lost sales, and some downtime causes are outside what monitoring can address, so it’s worth taking those out before finance does.
Remove non-addressable downtime. Operator-entered downtime codes are often vague or misclassified. Before you calculate ROI, split your records into:
- Addressable: mechanical and electrical failures that monitoring can detect early, such as bearings, misalignment, imbalance, lubrication, and motor faults.
- Not addressable: staffing gaps, changeovers and adjustments, waiting on material or upstream production, and failure modes outside the project scope.
Discount downtime that doesn't cost output. An hour down only becomes a lost sale if the plant can't recover it. Ask:
- Did a buffer or work-in-progress inventory absorb the stop?
- Is there spare capacity or a redundant asset?
- Can the volume be made up on another shift without overtime?
If the answer is yes, that hour belongs in the incremental-expense bucket (or nowhere), not in lost contribution.
A smaller, cleaner number wins approval faster than a large one that falls apart under one question.
Step 5: How do you break even if things go worse than planned?
Finance is less interested in your best case than in whether the investment still makes sense if things go worse than planned.
Build three scenarios from your addressable baseline:
Include the full cost of the investment in every scenario: sensors and software, installation, recurring subscription, and internal time to act on alerts. Hiding recurring costs is the fastest way to lose a renewal later.
Then calculate break-even, which is often the most persuasive number in the case.
If avoiding a handful of hours a year covers the cost, the conversation shifts from "will this pay back?" to "how much more will it return?"
Make sure you keep break-even and ROI distinct. Break-even is the point where savings equal cost (0% net return). A 100% ROI means savings are twice the investment. Mixing them up is a common reason models get sent back.
Step 6: How will you prove the savings after the fact?
Avoided failures are hard to prove because a failure that never happened leaves no invoice, so agree on the evidence trail with finance before the project starts.
Every avoided failure should follow the same chain:
- Alert: the system flags a developing fault, with the date and the asset.
- Inspection: a technician confirms the condition on site.
- Action: a planned work order records what was done and what it cost.
- Outcome: what was found (for example, a bearing with visible wear) and the failure it prevented.
- Approved valuation: the agreed cost of that failure, using the buckets from Step 3, signed off by finance or plant leadership.
This trail is much easier to keep when the alert, the diagnosis, and the work order live in one place. AI predictive maintenance software that connects sensor data to work orders builds the record as you go, instead of leaving it to spreadsheets someone has to reconcile at budget time.
Two rules keep the savings credible:
- No double-counting. A single event can't claim repair avoidance, lost production, and freed labor at full value unless each was actually at risk.
- Value hours as you go. Teams often log "hours of downtime avoided" without ever converting them to dollars. Agree on the hourly rate per asset up front so each verified event rolls straight into the ROI report.
This is what turns a one-time business case into a renewal and expansion case a year later.
What it looks like when the case holds up
Plants that build the case this way end up with something better than one savings figure: they have a model finance can check and a reporting habit that proves it each quarter.
Before: downtime is felt but not priced. Repairs are reactive, a few mechanics carry every emergency, and savings claims are hard to defend at budget time.
After: each critical asset has an agreed cost per hour. Faults are caught weeks ahead and fixed in planned windows. Every avoided failure is documented and valued, so the ROI report writes itself.
The business outcomes follow:
- Fewer lost production hours on bottlenecks and shared utilities
- Lower repair spend, with less secondary damage and fewer emergency rates
- Released maintenance capacity for planned and improvement work
- A budget case that survives review, and a renewal case that's already documented
What the published numbers show
Ingredion separated its results the same way this guide recommends. At one facility, Tractian condition monitoring delivered $1.0M in production savings and $223K in maintenance savings, with 48 to 168 hours of downtime avoided on critical equipment. Production value and repair cost are reported separately, which is what makes them credible.
At the model level, a Verdantix study commissioned by Tractian built a financial model for a mid-sized manufacturer ($200M revenue, 500 employees, 12 sites) and validated it through interviews with five Tractian customers. It found:
Treat these as a reference point for your base scenario rather than a promise. Your own baseline from Steps 1 to 4 is what finance will approve.
Your next step: put your own numbers in
You now know what an hour of downtime really costs and how to frame it for finance. Next, run your numbers:
- How to Build the Case for a Condition Monitoring Investment: a step-by-step template for baseline, assumptions, investment, risks, and validation.
- Verdantix Study: the full ROI model and what 60 maintenance and reliability leaders said about turning alerts into action.
- ROI Calculator for Online Condition Monitoring: enter your assets, downtime rates, and costs to see your break-even point.
Once the number holds up, the next question is what it takes to actually deliver those savings. Every line in this model depends on catching faults early enough to plan the repair, then proving each avoided failure after the fact. That’s the job of AI predictive maintenance software, and it’s what to look for next: https://tractian.com/en/blog/what-to-require-from-ai-predictive-maintenance-software-and-how-to-prove-it-in-90-days
Want to see how it works on your assets? Book a demo.