Evaluate how dependable a repairable system is. Adjust the operating hours, failure count and repair time to see MTBF (mean time between failures), availability, mission reliability and annual downtime update in real time, and check how many nines the design reaches.
Parameters
Operating hours T_op
h
Total time actually in service over the observation window (8760h = 1 year)
Number of failures N_fail
×
Total number of failures (stoppages) during the observation window
Mean time to repair MTTR
h
Average time from a failure to full recovery
Mission time t
h
Length of one operation you want to complete without failure
Results
—
MTBF mean time between failures (h)
—
Failure rate λ (/h)
—
Availability (%)
—
Mission reliability R(t) (%)
—
Annual downtime (h)
—
Availability rating
—
System life timeline — uptime (green) and repair (red)
Long green segments represent MTBF (uptime), short red segments represent MTTR (repair). The green fraction is the availability. The timeline scrolls left over time.
MTBF: mean time between failures (total operating hours T_op divided by the number of failures N_fail). A: availability. R(t): probability of completing a mission of duration t without a failure.
λ: failure rate (the reciprocal of MTBF, failures per hour). D_year: expected downtime per year. Availability A rises both by increasing MTBF and by decreasing MTTR.
What is MTBF and Availability?
🙋
Equipment datasheets often say things like "MTBF 50,000 hours". Does that mean it won't break for 50,000 hours?
🎓
That's a common misreading. MTBF is the "mean time between failures" — roughly, it tells you "if you ran many units of the same model, how often on average does one fail". It is not a per-unit lifetime guarantee. In a population with a constant failure rate, plenty of units fail before the MTBF. Treat it as completely separate from a "warranty period".
🙋
I see... So in practice, which number do I look at when I say "this system is dependable"?
🎓
The one used most is availability: A = MTBF / (MTBF + MTTR). MTTR is the mean time to repair — how long it takes to get back up after a failure. Availability is the fraction of all time that the system is actually up and able to do its job. Increase the failure count on the left and you'll see MTBF shorten and availability drop right away.
🙋
Oh, it does. But moving MTTR also changes availability. Which matters more — extending MTBF or shortening MTTR?
🎓
Good question — that's the heart of reliability design. Availability can be raised from both directions: by reducing failures (extending MTBF) and by speeding up repairs (shrinking MTTR). For a data-center server, you might duplicate components to cut failures, or stock spares so a swap takes ten minutes. Look at the "Availability vs MTTR" chart below — just shrinking MTTR pushes availability up sharply.
🙋
I also hear the phrase "five nines". Is that about availability?
🎓
Yes — five nines means 99.999% availability, five 9s in a row. To feel how strict that is, compute the allowed downtime per year. A year is about 525,600 minutes, so at 99.999% you may be down only about 5 minutes a year. Three nines (99.9%) allows 8.8 hours; four nines (99.99%) about 53 minutes. Telephone switches and financial systems aim for five nines, but that needs redundancy and automatic failover, and the cost climbs by orders of magnitude.
🙋
One last thing. Is "mission reliability R(t)" a different number from availability?
🎓
Yes — it answers a different question. Availability asks "what fraction of all time is it up". Mission reliability R(t) = e^(−t/MTBF) asks "what is the chance of completing one specific operation of length t without a single failure". It matters for things like a satellite launch, or one stage of a continuous-process plant you must not stop. For the same MTBF, the longer the mission, the faster R(t) decays — exponentially.
Frequently Asked Questions
MTBF (Mean Time Between Failures) is a metric for repairable systems — equipment that is fixed and kept in service — and is the average uptime from one failure to the next. MTTF (Mean Time To Failure) applies to non-repairable items such as light bulbs or fuses that are simply replaced when they fail, and is the average time from first use to failure. This tool deals with repairable systems, where MTBF = total operating hours / number of failures. The key difference is whether repair time MTTR is part of the picture at all.
Not necessarily. Availability is A = MTBF / (MTBF + MTTR), so even a long MTBF gives low availability if MTTR (repair time) is long. For example, an MTBF of 10,000 hours combined with a 500-hour repair yields only about 95.2% availability. Conversely, a short MTBF of 730 hours with an MTTR of 8 hours gives 98.9%. The key idea of reliability design is that availability can be improved both by reducing failures and by making repairs faster.
Five nines means 99.999% availability, which permits only about 5.3 minutes of downtime in a full year (8,760 hours = 525,600 minutes) — an extremely demanding level. Three nines (99.9%) corresponds to roughly 8.8 hours of downtime per year, and four nines (99.99%) to about 53 minutes. Telephone switches, core servers and financial systems target five nines, but reaching it requires redundancy, automatic failover and stocked spares, and the cost rises steeply.
No. MTBF is not a lifetime and not a warranty period; it is a statistical average failure rate expressed as a time. In a population with a constant failure rate, many units fail well before the MTBF. A hard disk advertised at an MTBF of 50,000 hours can still fail within five years (about 44,000 hours) with a non-negligible probability. MTBF describes how often, on average, one unit fails when many of that model run together — it is not a per-unit lifetime guarantee.
Real-World Applications
Data centers and IT infrastructure: The SLA (service-level agreement) for servers, storage and network gear is defined in terms of availability. To meet a contractual figure such as "monthly availability of 99.95% or better", designers roll up the MTBF and MTTR of each component — including whether redundancy is present — to estimate the availability of the whole system. Non-disruptive maintenance, hot-swap and automatic failover, which shrink MTTR, are among the most cost-effective investments for raising availability.
Manufacturing equipment maintenance (OEE): For factory production equipment, availability corresponds to the time-availability element of OEE (Overall Equipment Effectiveness), alongside performance and quality. To reduce stoppages from sudden failures, engineers monitor MTBF to catch degradation trends and use it to decide when to switch to planned or predictive maintenance. For the same machine, MTTR can vary several-fold depending on the repair organization and spare-parts inventory, directly affecting annual output.
Aerospace and defense: For satellites and aircraft systems, mission reliability R(t) is the design target. Because repair is impossible from launch to end of life, the question is not availability but "the probability of completing the mission period without a failure". Engineers build in redundancy, sum the failure rates λ of each subsystem and verify that the required R(t) is met.
Procurement and maintenance-contract evaluation: When buying or leasing equipment, the customer estimates post-deployment availability and annual downtime from the catalog MTBF and the contracted MTTR. A quick calculation like this tool — "for this MTBF and MTTR, how many hours of downtime per year?" — lets you compare proposals from several vendors on the same basis and discuss the trade-off between maintenance cost and lost-uptime cost quantitatively.
Common Misconceptions and Pitfalls
The biggest misconception is confusing MTBF with lifetime or warranty period. MTBF is not the time one product is guaranteed to keep running; it is a statistical average failure rate of a large population expressed as a time. If failures follow an exponential distribution with a constant rate, about 63% of a population fails before reaching the MTBF time. That is why a disk advertised at "MTBF 100,000 hours" still carries only a five-year (about 44,000-hour) warranty. Reading the MTBF figure as "per-unit lifetime" will badly throw off both maintenance planning and spare-parts provisioning.
Next, not checking the conditions behind an availability figure. The same "99.9%" means something completely different if the denominator is 24 hours × 365 days versus business hours only. The number also changes greatly depending on whether MTTR includes failure detection time, parts procurement lead time and post-repair verification. A frequent source of disputes is a vendor-quoted MTTR that covers "only the on-site work after arrival", excluding detection delay and parts wait. When comparing availability, always align "what is the denominator, and what is included in MTTR".
Finally, confusing high availability with mission reliability. Even at 99% availability, the success rate of a long mission is a separate matter. A system with MTBF 730 hours and 98.9% availability has only about a 37% chance R(t) of finishing a 720-hour continuous mission without a failure. "Almost always up day to day" and "running a specific long stretch without a single stop" are entirely different requirements. Availability can be raised with redundancy and fast repair, but raising mission reliability means either reducing failures themselves (extending MTBF) or breaking the mission into shorter segments. Depending on the use case, do not mistake which metric to watch.
How to Use
Enter total operating hours in hoursNum (e.g., 8760 for one year of continuous operation)
Input the number of failures observed during that period in failNum
Specify mean time to repair (MTTR) in hours—typical values: 2h for field maintenance, 0.5h for automated systems
Set mission duration in missionNum to calculate reliability for that specific timeframe
The simulator computes MTBF, failure rate λ, availability percentage, and annual downtime automatically