Time to Failure
Time to Failure defines how long a node operates before an interrupt occurs. It represents the active period between interruptions and is used to model events such as random equipment failures, scheduled downtime, wear-out conditions, or volume-based triggers.
In ReliaSim®, Time to Failure is defined using a statistical distribution. Each time an interrupt is evaluated, a new value is sampled from this distribution and compared against either elapsed wall time, accumulated uptime, or processed volume—depending on the selected interrupt type. This allows failure behavior to reflect both predictable schedules and real-world variability.
Time to Failure can be driven by elapsed time, uptime, or throughput volume, and can operate in either competing or cumulative modes. Competing behavior is typically used for random failures where multiple potential causes may independently trigger an interrupt. Cumulative behavior is better suited for wear-based or consumption-driven scenarios, where progress toward failure builds gradually over repeated operating cycles.
By adjusting Time to Failure distributions, you can explore how reliability affects throughput, efficiency, and system stability. Even small changes in failure frequency can have significant downstream effects, making this parameter one of the most important levers for realistic modeling.
Three intervals, one cycle
Time to failure, repair time and time between failures name different parts of the same cycle, and they are routinely used as if they were interchangeable.
The wall-clock gap from one failure to the next contains both. Note that the METRIC called MTBF is not this gap — it is total operating hours divided by failures, which is the green interval.
- Time to failure — running time, from the moment the machine is up to the moment it stops. This is what you configure on an interrupt.
- Time to repair — from the stop until it is running again.
- Time between failures — the wall-clock gap from one failure to the next, which contains both of the above.
Here is the part that trips people up. The interval labelled above is the wall clock: a machine that runs 30 minutes and takes 5 to fix goes 35 minutes between failures. But the metric everyone calls MTBF is not that interval — it is
MTBF = total operating hours ÷ number of failures
which is running time only: 30 minutes, not 35.
Published definitions do not agree on that numerator — some use operating hours, others total elapsed time — and each is correct only with its own availability formula:
| MTBF numerator | Availability formula that matches it |
|---|---|
| operating hours ÷ failures | A = MTBF ÷ (MTBF + MTTR) |
| elapsed time ÷ failures | A = (MTBF − MTTR) ÷ MTBF |
Both reproduce the same answer. Mixing them does not: taking MTBF over elapsed time and putting it through the first formula counts the repair twice, and on a line where stops are short and frequent that is worth fifteen percentage points, not a rounding error.
The way past the whole problem is to state availability the way it is actually defined, which needs no convention:
Availability = uptime ÷ (uptime + downtime)
ReliaSim reports MTBF on operating hours, so its figures pair with the first formula. The diagram above is a picture of intervals; the metric is a ratio of totals. Same three words, different things counted.
The "M" is a mean over many cycles
The timeline above is one cycle. Nobody quotes one cycle — MTBF, MTTF and MTTR are all means taken over many, and that is the part a single-cycle diagram cannot show.
MTBF is a mean over many cycles
14 consecutive cycles on one machine. Running time in green, repair in red.
No two cycles the same length.
The same 14 running times, as a distribution
Running time before the stop (minutes). Shortest run under a minute, longest 163. Only 3 of the 14 land near the mean — averaging keeps the one number and discards the rest of this picture.
Fourteen cycles sampled from the same Weibull(30, 1) the demo models use. The mean running time is 31 minutes, and almost none of the runs is near 31: eight are under 20 minutes, and one goes 163. Averaging keeps the 31 and discards everything else about that picture.
Which is why a mean is a summary and not a specification. Two machines reporting the same MTBF can behave completely differently — one stopping predictably, the other mostly running briefly with rare long stretches — and a buffer downstream responds to them in completely different ways. The distribution is the input; the mean is one thing you can calculate from it afterwards.
What a distribution parameter is not
A distribution's parameters are not its mean, and the difference matters when reading results back.
For a Weibull, the scale is the running time by which 63.2% of runs have ended; the mean is scale × Γ(1 + 1/shape). These coincide only when the shape is exactly 1 — the exponential case, constant failure rate. So a Weibull with scale 30 and shape 1 does have a mean time to failure of 30 minutes, but the same scale with shape 2 has a mean of about 26.6. Reading a scale parameter as "the MTBF" is the most common way to misread a fitted failure mode.
And a fitted time to failure is an input describing one failure mode in isolation. The MTBF a model reports is an output describing the node as it actually ran — with every other interrupt competing against it, and with the node idle whenever it was starved or blocked. The two are different numbers answering different questions, and they are rarely equal.
Competing interrupts divide the time between stops
When several interrupts are armed on one node in competing mode, each counts down independently and the first to fire stops the node. You are therefore waiting for the earliest of several clocks, not for any particular one.
Risks accumulate rather than average, so the node stops far more often than any single interrupt would make it — roughly in proportion to how many are armed.
How much more often is a result of the run. It depends on how many interrupts are armed, on each one's distribution and shape, on how long repairs take, and on how much of the time the node is starved or blocked and therefore accumulating no risk at all. Those interact, which is why the answer is measured rather than derived.
The One Constraint, Five Interrupts demo is the simplest version of this measured rather than estimated: five interrupts at Weibull(30, 1) on one Constraint produced 5.8 minutes between stops across 11,964 events over 90 simulated days. Every one of those stops happened because a particular clock reached zero before four others.
This is why a line's observed reliability is always worse than any single machine's specification, and why a machine's MTBF cannot be read as the line's.
Time to Repair
Time to Repair defines how long a node remains unavailable once an interrupt has occurred. It represents recovery activities such as maintenance, resets, refilling, or operator intervention, and directly impacts how quickly normal operation resumes.
Like Time to Failure, Time to Repair is defined using a statistical distribution. Each interruption samples a repair duration, allowing downtime to vary from event to event. This makes it possible to model both consistent recovery times and highly variable repair processes.
While Time to Failure controls how often interruptions occur, Time to Repair determines how disruptive those interruptions are. Short repairs may have minimal impact on overall performance, while longer or more variable repairs can significantly increase upstream accumulation and downstream starvation.
Together, Time to Failure and Time to Repair define the reliability profile of constrained operations. By tuning both parameters, you can evaluate the impact of maintenance strategies, staffing levels, spare parts availability, and process improvements—helping prioritize actions that most effectively improve system performance.