Guide
MTBF and MTTR for oil & gas maintenance teams.
Four numbers carry most of the weight in a reliability review. This page says exactly how RelyentX computes each one and which denominator it used, because that detail decides whether the number means what you think it means.
The four numbers, plainly
Mean time between failures (MTBF) is the average time from one failure to the next, across a population of equipment. Mean time to repair (MTTR) is the average time a failure takes to put right. Mean time to failure (MTTF) is the average time equipment spends running between repairs, which is MTBF minus the repair time. Availability is the share of the period the equipment was not under repair.
They answer different questions. MTBF tells you how often you are interrupted, MTTR how expensive each interruption is to recover from, and availability what the two together cost you in the end. A fleet with a long MTBF and a terrible MTTR is a fleet that fails rarely and then stays down for weeks.
Where the numbers come from in RelyentX
A failure is a job card of a work type your workspace has named as a failure, and out of the box that is corrective work only. Preventive and modification work is then excluded from the failure count, so planned work does not depress your MTBF. Someone with the analytics-configuration permission can change which work types count, and every failure figure follows the same setting.
Repair time comes off the card itself. Each closed corrective card carries a per-card MTTR, which is its close date minus its start date in whole days, and never less than one day: a card opened and closed on the same day counts as one. Read that literally: it is how long the card was open, so it includes waiting for a part, a permit or a crew, not only the hours someone spent on the tools. A repair that took an afternoon but waited nine days for a seal counts as ten days.
From there the aggregates are short. MTTR is downtime over restored failures. MTBF is calendar time over failures. MTTF is MTBF minus MTTR, never below zero, and availability is that MTTF over MTBF, as a percentage. A type with no failure in the window has no MTBF, so its MTTF and availability are blank rather than shown as 100 percent.
All of it is computed when you ask, from the job cards and the equipment master, and none of it is stored. There is no nightly rollup to go stale and no reconciliation step to forget: change a close date and the number changes with it.
Our denominator, in full
Calendar time here is the equipment count multiplied by the number of days in the window. Ten pumps over ninety days is nine hundred equipment-days, whether those pumps ran continuously, ran on rotation, or sat on a rack the whole quarter.
That is a calendar basis, not an operating-hours basis. RelyentX does not currently take a working-hours or runtime-meter feed, so it cannot tell a pump that ran 24/7 from one that was a cold standby. We say so here rather than let you infer an operating-hours figure from a calendar one.
What follows from that is worth knowing before you compare vendors. On a calendar basis, adding spare equipment to a class raises its MTBF and its availability without anything mechanical improving, because the denominator grew and the failure count did not. Compare like with like: the same equipment type, the same window, and a population that has not changed size underneath you.
One more thing the window does. If you set no dates, the window is the twelve months ending today. Change the dates and you change the denominator and therefore the figure. That is correct behaviour and it surprises people: two screens showing different MTBFs for the same equipment are usually two different windows, not a bug. Open work, such as the backlog and its aging, is the exception when you chose no dates: a card open for thirteen months still counts, because it is still open.
The honest use of a calendar-based number is as a trend and a comparison between types, not as an absolute to put in a contract. It is the number your job cards actually support. An operating-hours figure would need a data source that is not there, and inventing one would make the number look better and mean less.
Availability is derived, not measured
The availability percentage here is the share of the gap between failures that was not spent on repair, taken from closed failure cards. It is not a reading from a control system, a historian or a sensor, and it does not know about a process upset that left equipment idle without a repair.
This means availability inherits every property of the inputs. A corrective card left open past the repair does not accrue downtime until it closes, so a backlog of unclosed cards flatters the number. That is a property of deriving availability from work orders rather than reading it off an instrument, and it is worth knowing before the figure is quoted at anyone.
PM compliance, and what it depends on
Preventive-maintenance compliance is reported from your PM plans. Of the planned maintenance that fell due in the window, it is the share done on or before its due date, shown beside the number of equipment due. One done late counts as due and not compliant, one still ahead of today is left out, and when none fell due the figure is blank rather than zero. Overdue PM is counted separately, and it is a state of now: any occurrence past its due date and not done, whatever window you are looking at.
It is only as good as the plans behind it: equipment with no PM plan has nothing due and so does not appear in the count at all, and a plan that was never kept up to date will make compliance look better or worse than the shop floor is.
What these numbers will not do
They will not predict a failure. RelyentX measures reliability from the events your work already produced; there is no forecasting model and no anomaly detection in the product, and the site does not claim any.
They will also not tell you why. That is what the work history is for, and it is the question Root is actually good at: ask why an asset keeps failing and the answer is retrieved from that asset’s own closed cards, certificates and status history, with those records shown next to it so you can check them.
Common questions
Is MTBF calculated on operating hours or calendar days?
Calendar time, not operating hours. Calendar time is the equipment count multiplied by the days in the window, and RelyentX does not take a runtime-meter or working-hours feed today, so it cannot distinguish running time from idle time. The dashboard shows them in hours by default and in days at a click, but either way they are calendar time counted from whole-day job-card dates, comparable across equipment types and over time rather than quotable as absolute operating-hours reliability.
Does preventive work count as a failure?
Not by default. Out of the box only corrective job cards count as failures, and preventive and modification cards are counted separately, so planned maintenance does not damage your MTBF. Someone with the analytics-configuration permission can change which work types count as a failure, and every failure figure follows that setting.
Why did our availability improve when we added equipment?
Because availability is taken from MTBF, and MTBF is calendar time over failures, where calendar time is the equipment count multiplied by the window. Adding equipment to a type grows the denominator immediately while the failure count takes time to follow. Compare windows where the population is stable, or compare types against each other rather than a type against its own past.
Are the numbers stored or recomputed?
Recomputed on every read, from the job cards and the equipment master. Nothing is persisted, so correcting a close date corrects every figure that depended on it, with no rebuild step.
Guides
See it against your own equipment data.
A walkthrough on your asset classes, your certificate disciplines, your job cards, not a canned demo.