MTBF, MTTR and Availability Explained

Reliability engineering lives on three numbers that most maintenance teams already have buried in their work orders: how long equipment runs before it breaks, how long it takes to get it running again, and what fraction of the time it is actually available to do its job. Those three numbers are MTBF, MTTR and availability. They sound like jargon, but each one is a simple average you can compute with a calculator and a maintenance log. The value is not in the math. It is in what the numbers tell you to do next.

This guide walks through each metric, states the formulas plainly, and works a full example from a single machine so you can see how the pieces connect. Then it covers how to read the result, the mistakes that quietly ruin these numbers, and the situations where MTBF and availability stop being the right tool. By the end you should be able to pull a year of failure records and turn them into an availability figure you can defend in a review.

What MTBF, MTTR and availability actually mean

MTBF stands for mean time between failures. It is the average amount of running time a repairable asset delivers between one failure and the next. If a pump gives you long stretches of uptime, its MTBF is high. If it keeps tripping, its MTBF is low. The word “between” matters: MTBF is for equipment you repair and return to service, not for parts you throw away after one failure. For non-repairable items the matching term is MTTF, mean time to failure, and it is measured a little differently.

MTTR stands for mean time to repair. It is the average time it takes to restore a failed asset to working order, counting the hands-on repair work. Some teams stretch MTTR to include waiting for parts, waiting for a technician, and diagnosis, while others keep it to wrench time only. Both are valid as long as you are consistent, but they answer different questions, so decide up front which one you mean and label it clearly.

Availability is the fraction of time an asset is ready to perform when you need it. The version we use here is inherent availability, which looks only at failures and repairs and ignores planned maintenance, weekends, and idle shifts. It answers a focused question: given how often this thing breaks and how long it takes to fix, what share of its intended running time can you actually count on?

The formulas

Here are the relationships in plain form. Every one of them is an average or a ratio, so there is nothing exotic to compute.

MTBF = total uptime / number of failures

MTTR = total repair time / number of repairs

Availability A = MTBF / (MTBF + MTTR)

Failure rate lambda = 1 / MTBF

Reliability R(t) = e^(-t / MTBF) = e^(-lambda t)

The first three are the core trio. The failure rate lambda is just the reciprocal of MTBF, and it is handy because failure rates add up across components in a way that MTBF values do not. The reliability function R(t) assumes a constant failure rate, which is the flat middle of the classic bathtub curve, and it tells you the probability that the asset survives a mission of length t with no failure. That last formula is where MTBF stops being a bookkeeping number and starts predicting outcomes.

One relationship worth sitting with: availability depends on the ratio of MTBF to MTTR, not on either one alone. A machine with a huge MTBF and a slow repair can end up with the same availability as a machine that fails often but is fixed in minutes. That is why you never report availability without also reporting the two numbers behind it.

How to calculate it step by step

You need three inputs from your maintenance records for a defined window of time: the total hours the asset was actually running, the number of failures in that window, and the total hours spent repairing those failures. Everything else follows.

Step one, set your window and your definition of a failure. A common trap is counting minor stops, tool changes, or planned pauses as failures. Decide what a failure is before you start, and count only unplanned stoppages that required a repair. Step two, add up running hours. Step three, count failures and divide to get MTBF. Step four, add up repair hours and divide by the number of repairs to get MTTR. Step five, drop both into the availability formula. Step six, if you need reliability for a mission length, take lambda as one over MTBF and use the exponential formula.

If you would rather not do this by hand, the MTBF, MTTR and Availability Calculator takes those same inputs and returns all three metrics plus the failure rate. It is the fastest way to check your arithmetic before a meeting.

A full worked example

Take one machine over a defined window. It runs 1,000 hours and fails 5 times during that window. The math for MTBF is straightforward:

MTBF = 1,000 / 5 = 200 hours

So on average the machine delivers 200 hours of running time between failures. Now the repairs. Across those 5 failures the maintenance team logged 25 hours of total repair time. That gives:

MTTR = 25 / 5 = 5 hours

Each repair takes 5 hours on average. With both numbers in hand, availability falls out directly:

A = 200 / (200 + 5) = 200 / 205 = 0.9756 = 97.56 percent

So this machine is available about 97.56 percent of the time it is meant to run. The failure rate is the reciprocal of MTBF:

lambda = 1 / 200 = 0.005 per hour

Now ask a forward-looking question. What is the chance the machine completes a 100-hour production run with no failure? Use the reliability formula:

R(100) = e^(-100/200) = e^(-0.5) = 0.607

That is about a 61 percent chance of finishing the 100-hour mission without a single failure. Put another way, roughly 4 runs out of 10 would be interrupted. For a critical order, 61 percent is not comforting, and that single number often does more to justify a reliability project than any availability figure.

The lesson from this example is the reason you track failures and repairs separately. The same availability can come from very different MTBF and MTTR pairs, and each pair calls for a different fix. If you only stored the availability figure, you would have thrown away the information that tells you whether to work on reliability or on repair speed.

How to read and apply the result

Availability by itself is a scoreboard, not a diagnosis. The diagnosis comes from the pair behind it. When MTBF is low, the machine fails too often, and your work is reliability: root cause analysis, better components, condition monitoring, design changes. When MTTR is high, the machine is fine but your response is slow, and your work is maintainability: spare parts on the shelf, better procedures, trained technicians, faster diagnosis.

For most teams, MTTR is the faster lever. Raising MTBF means changing the physics of failure, which can take months and capital. Cutting MTTR means changing how your team responds, which you often control this week. Stocking a critical spare, writing a clear repair procedure, or pre-staging tools can shave hours off a repair with almost no capital. That is why the worked example put the repair improvement first.

Translate availability into money before you present it. A machine at 97.56 percent availability is down about 2.44 percent of its intended running time. Over a 6,000-hour operating year that is roughly 146 hours of lost production. Multiply that by the contribution margin per hour and you have the annual cost of the current availability, which turns an abstract percentage into a number the finance team recognizes.

Common mistakes that ruin these numbers

The first mistake is mixing planned and unplanned downtime. Inherent availability counts only failures and repairs. If you let scheduled maintenance, changeovers, or a lack of orders into the downtime bucket, you are computing something closer to operational availability, which is a different metric with different uses. Keep the buckets separate and label which availability you mean.

The second mistake is inconsistent failure definitions. If one shift logs a 3-minute reset as a failure and another does not, your failure count is noise and MTBF is meaningless. Write the definition down and hold everyone to it.

The third mistake is averaging across a fleet without thinking. MTBF is an average, and averages hide their tails. Ten reliable machines and one problem machine can produce a healthy fleet MTBF that hides the asset actually hurting you. Look at the distribution, not just the mean, and be ready to compute per-asset numbers.

The fourth mistake is treating the reliability formula as universal. R(t) = e^(-lambda t) assumes a constant failure rate. That holds during the useful-life middle of an asset’s life, but not during early-life infant mortality or the wear-out phase at the end. Use the exponential model where it fits and reach for a Weibull model where it does not.

When MTBF and availability do not apply

These metrics assume a repairable asset with a roughly constant failure rate over the window you are studying. Several situations break that assumption. Wear-out items, such as bearings or belts near the end of life, have a rising failure rate, so a single MTBF understates the risk as the part ages. Infant mortality, the early failures after installation or a rebuild, has a falling rate that MTBF also smears over. In both cases a Weibull analysis is the honest tool because it fits the shape of the failure curve instead of forcing a flat rate.

MTBF and availability also say nothing about consequence. A failure that stops a whole line and a failure that a redundant unit absorbs both count as one failure, but they are not equal risks. To rank failures by severity, occurrence, and detectability you need a FMEA and RPN analysis, which prioritizes what to fix rather than just measuring how often things break. And when you are modeling a system of many components rather than one machine, availability of the whole depends on how the parts are arranged, which is the job of a system reliability calculation for series, parallel, and k-of-n configurations.

Three expert tips

Report the pair, never the single number

Availability alone hides the action. Always present MTBF and MTTR alongside it, because the same 97.56 percent can mean “fails rarely, slow to fix” or “fails often, fast to fix,” and those two stories need opposite responses. A dashboard that shows only availability trains people to celebrate or panic without knowing which lever to pull.

Attack MTTR first when you need a quick win

Improving MTBF usually means engineering out a failure mode, which is slow and often expensive. Cutting MTTR means improving your response, which is frequently within reach this quarter. Pre-staged spares, a written repair procedure, and a trained first responder can halve repair time and lift availability more than a month, as the worked example showed when 5 hours dropped to 2.5.

Convert availability to hours and dollars every time

A percentage does not move budgets. Turn 2.44 percent unavailable into lost production hours over the operating year, then into lost margin. When a reliability project is framed as recovering 146 hours and the money attached to them, it competes for funding on equal footing with everything else, instead of sounding like an engineering nicety.

Free maintenance and reliability calculators

If you want to run these numbers on your own equipment, the tools below cover the full workflow from a single asset to a whole system. Start with the MTBF calculator for the metrics in this article, then move to Weibull, FMEA, or system reliability as your question gets more specific. You can also browse the full Maintenance and Reliability hub for the complete set.

• MTBF, MTTR and Availability Calculator (Free)
• Failure Rate and Reliability Calculator (Exponential)
• Weibull Analysis Calculator (Shape, Scale, B10 Life)
• FMEA / RPN Calculator (Risk Priority Number and Action Priority)
• System Reliability Calculator (Series, Parallel, k-of-n)
• Preventive Maintenance Calculator (Optimal Replacement Interval)

Frequently asked questions

What is the difference between MTBF and MTTF?

MTBF, mean time between failures, is for repairable assets that you fix and return to service, so it measures the average uptime between one failure and the next. MTTF, mean time to failure, is for non-repairable items you replace after a single failure, so it measures the average life until that one failure. Use MTBF for a pump or motor you repair, and MTTF for a component like a bulb or a fuse.

How do I calculate MTBF from my maintenance records?

Pick a window of time, add up the total hours the asset was actually running, and count the number of unplanned failures in that window. Divide total running hours by the number of failures. In the worked example, 1,000 running hours with 5 failures gives an MTBF of 200 hours. The key is counting only genuine failures, not planned stops or minor resets.

Does MTTR include waiting for parts and diagnosis?

It depends on the definition you choose. A strict “mean time to repair” counts only hands-on repair work. A broader “mean time to restore” or “mean time to recovery” includes detection, diagnosis, waiting for parts, and testing. Both are valid, but they answer different questions, so pick one, label it clearly, and apply it the same way every time.

What is a good availability number?

There is no universal target because it depends on the cost of downtime and the criticality of the asset. A non-critical machine might be fine at 95 percent, while a bottleneck asset or a safety system may need 99.9 percent or higher. Rather than chasing a generic benchmark, translate your current availability into lost hours and lost margin, and set a target where the cost of improvement is justified by the value recovered.

Why does cutting MTTR improve availability faster than raising MTBF?

Availability depends on the ratio of MTBF to MTBF plus MTTR, so both levers work. But raising MTBF means engineering out a failure mode, which is slow and often needs capital. Cutting MTTR means improving your response with spares, procedures, and training, which you frequently control right now. In the worked example, halving MTTR from 5 hours to 2.5 hours lifted availability from 97.56 percent to 98.77 percent with no change to how often the machine failed.

What does the reliability formula R(t) = e^(-t/MTBF) tell me?

It gives the probability that an asset runs for a mission of length t with no failure, assuming a constant failure rate. In the example, MTBF is 200 hours, so a 100-hour mission has reliability e^(-0.5) = 0.607, about a 61 percent chance of no failure. It converts an average uptime into a probability for a specific job, which is far more useful for planning a critical run than MTBF alone.

Can I add MTBF values together for a system?

No, MTBF values do not add. Failure rates do. Convert each component’s MTBF to a failure rate lambda equal to one over MTBF, add the failure rates for components in series, then invert to get the system MTBF. For anything beyond a simple series arrangement, including parallel redundancy or k-of-n voting, use a system reliability calculator that handles the configuration properly.

When should I use Weibull analysis instead of MTBF?

Use Weibull when the failure rate is not constant, which is most wear-out and early-life situations. The simple MTBF and exponential reliability model assume a flat failure rate, valid only in the useful-life middle of an asset’s life. Weibull fits the actual shape of the failure curve through its shape parameter, so it correctly captures parts that fail more as they age or components with early infant mortality.

What is the difference between inherent and operational availability?

Inherent availability counts only failures and repairs, so it reflects the equipment design and maintainability, using MTBF and MTTR. Operational availability includes everything that keeps an asset from running, such as planned maintenance, waiting for operators, supply delays, and idle time. Inherent availability is higher and is best for engineering decisions, while operational availability reflects what the plant actually experiences.

How many failures do I need before MTBF is trustworthy?

MTBF from a handful of failures carries a wide confidence interval, so treat small samples with caution. A single failure gives you almost no confidence in the true rate. As a rough guide, you want enough failures that adding one more does not swing the average much, often meaning several failures at minimum and ideally ten or more. Where data is thin, report the uncertainty rather than a single point number.

Does availability account for the severity of a failure?

No. Availability treats every failure the same, whether it stopped the whole line or was absorbed by a backup unit. To rank failures by how bad they are, use an FMEA that scores severity, occurrence, and detectability and produces a risk priority number. Availability tells you how much time you lose, while FMEA tells you which failures deserve attention first.

Should I compute these metrics per asset or for a whole fleet?

Both have a place, but start per asset. A fleet average can hide one problem machine behind many good ones, so a healthy fleet MTBF may still mask the asset that is actually costing you. Compute per-asset numbers to find where to act, then roll up to a fleet figure for reporting. Always look at the distribution, not just the mean.

MTBF, MTTR and availability are only worth tracking if they change what you do. Compute them per asset, keep failures and repairs in separate columns, and read the pair before the percentage. When you know whether the problem is how often equipment fails or how slowly you fix it, the next move becomes obvious, and the numbers stop being a report and start being a plan. Run your own figures through the MTBF, MTTR and Availability Calculator and take the pair, not just the score, into your next reliability review.