An uptime guarantee sounds like a promise about reliability. In practice it is a promise about a number, and the number has to be measured by someone. Research on these contracts makes the point sharply. In a study published in Production and Operations Management, Hezarkhani, Nagarajan and Tong analyse maintenance contracts between an equipment manufacturer and the operator of its equipment, and note that the service provider’s maintenance effort “is noncontractible.” The customer cannot see how hard the manufacturer is trying. What both sides can see, if they measure it, is whether the machine was running.
That is why uptime contracts pay on outcomes. And it is why the definition and measurement of downtime decide whether such a contract works or turns into a monthly argument.
Key Takeaways
- Uptime guarantees pay on outcomes because the customer cannot directly verify the manufacturer’s maintenance effort.
- Every such contract depends on agreeing when the machine was down, which hours counted, and why it stopped.
- The customer also affects uptime, so the contract has to separate downtime the manufacturer caused from downtime it did not.
- A record produced by the machine itself is the most practical way to keep the measurement out of dispute.
Why These Contracts Pay on Outcomes
Traditional service contracts pay for inputs: a number of visits, hours of labour, parts supplied. The customer pays whether or not the machine stays running, and the manufacturer earns more when it breaks more often.
An uptime guarantee reverses the incentive. The manufacturer is paid for the machine being available, and pays, in some form, when it is not. The researchers describe one structure in which the provider “simply guarantees 100% uptime” and compensates the operator for any downtime at a higher unit rate than it charges for maintenance. Whatever the exact form, the effect is the same: the manufacturer’s income now depends on a measured outcome rather than on work performed.
The paper cites Philips Healthcare’s uptime-guarantee contracts for medical imaging equipment as one real-world example, and notes that for devices such as MRI scanners and jet engines “the manufacturer monitors the device’s performance remotely on a real-time basis.” That is not a coincidence. Where uptime is guaranteed, uptime is measured.
Downtime Is Harder to Define Than It Sounds
Everyone agrees on what downtime means until they have to write it into a contract. Then the questions arrive.
When does the clock start: when the machine fails, when the customer notices, or when the customer reports it? When does it stop: when the technician leaves, or when the machine is back in productive use? Does a machine that runs at reduced capacity count as up or down? Is planned maintenance excluded, and who decides what was planned?
None of these has a single right answer. Each has to be answered explicitly, because each shifts money between the parties every month the contract runs. A definition left vague at signing becomes the subject of the first dispute.
Which Hours Count
The research draws a distinction that matters in practice: between workable time, when the customer actually needs the machine, and non-workable time, when it would not have been used anyway. In the contract structures it examines, the provider pays when the machine is down “during the workable time (no payments during nonworkable times).”
That distinction is fair, and it is also a source of disagreement. A machine that fails on Friday evening and is repaired on Monday morning may have been down for sixty hours and cost the customer nothing, or it may have stopped a weekend shift. The paper itself observes that one contract structure has the advantage that “the parties do not need to monitor or reach consensus regarding the nonworkable times,” precisely because agreeing on them is hard.
The practical conclusion is that the contract needs a reliable way to know when the machine was actually meant to be working, not only when it was broken.
The Customer Affects Uptime Too
Not all downtime is the manufacturer’s doing. The researchers explicitly incorporate “the customer’s ability to affect the uptime,” and any real contract has to as well.
Machines stop because they fail, and they also stop because an operator did not turn up, a power supply dropped, the machine was misused, a consumable ran out, or someone switched it off. An uptime guarantee that cannot tell these apart either penalises the manufacturer for things outside its control or leaves the customer suspicious that every stoppage will be blamed on them.
Separating the causes requires evidence about the machine’s state at the time: was it powered, was it running, what did its electrical system do before it stopped? Without that, cause is decided by whoever tells the more convincing story.
Who Keeps the Record
In many service relationships, downtime is recorded by the party with the most to gain from the number. The customer logs when the machine went down. The service provider logs when the ticket was opened and closed. The two records rarely agree, and neither is independent.
A record produced by the machine itself changes the conversation. If the machine reports when it stopped running and when it restarted, the start and end of downtime are facts rather than claims. Disputes narrow to the genuinely contestable questions, such as cause and whether the hours were workable, instead of the basic timeline.
Repair speed still matters, of course. The time a machine spends down is heavily shaped by whether the first visit fixes it, which is the subject of how manufacturers improve first-time fix rates.
What to Put in the Contract
Define downtime precisely: what state counts as down, when the clock starts and stops, and how reduced capacity is treated. Define which hours count, preferably tied to the customer’s actual operating pattern rather than a fixed calendar. List the exclusions, such as planned maintenance, power loss and customer-caused stoppages, and say what evidence establishes each. Agree the source of truth for the timeline, and make it visible to both parties. And set the compensation so that it reflects what downtime actually costs the customer, which is the logic behind the operator-side view in how to prevent equipment downtime before it costs you.
A manufacturer that has measured how its machines actually run is also far better placed to price the guarantee in the first place.
Where ARMOR™ Fits
ARMOR™ produces the timeline an uptime guarantee depends on. ARMOR 4+™ wires into the machine’s electrical system and reports runtime hours, voltage and current into ARMOR Asset Central™, so when a machine stopped running, when it restarted and how its electrical system behaved around the stoppage are recorded by the equipment itself.
Because the manufacturer, dealer and customer can each see the same record, the start and end of downtime stop being a matter of competing logs. ARMOR™ does not write contracts, decide cause or calculate compensation, and a guarantee still needs clear definitions agreed by both sides. It supplies the shared facts those definitions are applied to.
The unit installs non-destructively on standard wiring harnesses, with no bill-of-materials redesign. How it is built in at the production stage is set out on the ARMOR™ for Equipment Manufacturers page.
Frequently Asked Questions
Should we guarantee 100% uptime?
Research suggests that structures built around a full guarantee with compensation for downtime can serve the provider well in many situations. Whether it suits your product depends on its reliability, your service reach and how well you can measure downtime. A guarantee you cannot measure is a liability, whatever the percentage.
Can the machine tell us why it stopped?
Partly. Electrical and runtime data can show whether a machine lost power, stopped under load or was switched off, which separates many causes. Some causes, such as operator absence, still need context from the customer.
What about planned maintenance?
It is normally excluded, but define it. Planned work that overruns, or maintenance the customer postponed, are common grey areas and are easier to resolve when both parties can see when the machine was actually down.
Is this only for high-value equipment?
The real-world example in the research comes from medical imaging, where downtime is very expensive. The logic applies to any equipment whose downtime costs the customer real money, provided both sides can agree how downtime is measured.
See how ARMOR™ is built into equipment like yours, at the build stage. ARMOR™ for Equipment Manufacturers
