MTBF, MTTR & Availability Calculator

Availability is how often something fails set against how fast you recover. Enter how long a component runs between failures and how long each recovery takes to get availability, yearly downtime, and how dependencies stack up.

ad placeholder — remove this div, insert an ad unit after AdSense approval

From MTBF and MTTR

One component
hours

Average time the component runs before it fails. Example: 2000 hours ≈ 83 days.

hours

Average time to detect, fix and restore service after a failure.

How many components like this one must all be up for the whole system to work.

Results

Availability (one component) —

MTBF ÷ (MTBF + MTTR) — the share of time this component is up.

Downtime per year—

(1 − availability) × 8,766 hours.

Failures per year—

8,766 ÷ (MTBF + MTTR).

System availability (in series)—

Each component's availability multiplied together: A raised to the number of components.

System downtime per year—

Yearly downtime once every component in the chain is counted.

See how chaining parts adds downtime

Downtime per year as more parts depend on each other

    Each extra part in the chain must be working for the whole system to work, so downtime grows quickly. The highlighted row is the number of parts you entered.

    Work backwards from a target

    Pick the availability you need and see how reliable each part has to be — or how fast recovery has to get.

    Target

    What you need
    %

    The availability you are aiming for.

    hours

    Your recovery time, to work out the MTBF you would then need.

    hours

    Your time between failures, to work out the MTTR you would then need.

    What it takes

    MTBF needed —

    Time between failures required to hit the target, if recovery time does not change. = MTTR × A ÷ (1 − A).

    MTTR needed—

    Recovery time required to hit the target, if the failure rate does not change. = MTBF × (1 − A) ÷ A.

    Allowed downtime per year—

    (1 − target) × 8,766 hours.

    The formula

    Availability = MTBF ÷ (MTBF + MTTR). Uptime over uptime plus downtime. Two levers move it: fail less often (raise MTBF) or recover faster (lower MTTR). They are symmetric in the maths — halving MTTR helps availability exactly as much as doubling MTBF — but recovery is usually the cheaper one to improve, through faster alerting, automated rollback and tested failover.

    Dependencies compound

    Components in series all have to be up at once, so their availabilities multiply. Ten dependencies at 99.9% each give a system at 0.99910 ≈ 99.0% — a tenfold increase in downtime. This is why teams count their critical-path dependencies and why "just add another service" is never free. Redundancy works the other way: two independent copies at availability A give 1 − (1 − A)², turning 99% into 99.99% — provided the failures really are independent and failover actually fires.

    AvailabilityDowntime / yearDowntime / month (30d)
    99%3d 15h 36m7h 12m
    99.9%8h 45m 36s43m 12s
    99.99%52m 34s4m 19s
    99.999%5m 15s26s

    Frequently asked questions

    How do you calculate availability from MTBF and MTTR?

    Availability = MTBF ÷ (MTBF + MTTR). If a component runs for 2,000 hours between failures and takes 2 hours to recover, availability is 2000 ÷ 2002 ≈ 99.9%.

    What is the difference between MTBF, MTTF and MTTR?

    MTBF (mean time between failures) is the average time from one failure to the next, for something you repair. MTTF (mean time to failure) is the average lifespan of something you replace. MTTR (mean time to recovery, or repair) is how long you are down each time. For high-availability systems MTBF and MTTF are close enough to use interchangeably here.

    Why does adding dependencies make availability worse?

    Components in series all have to be up for the system to be up, so their availabilities multiply. Five components at 99.9% each give a system at 0.999^5 ≈ 99.5%. Every dependency you add spends some of your reliability budget.

    Is it better to fail less often or recover faster?

    Both raise availability, but recovery is often the cheaper lever. Cutting MTTR in half does as much for availability as doubling MTBF, and faster detection, rollback and failover are usually more achievable than making a component fail half as often.

    How does redundancy change the maths?

    Two identical components in parallel (either one keeps you up) give availability 1 − (1 − A)². Two things at 99% become 99.99% together — as long as the failures are truly independent and failover actually works.

    ad placeholder — in-content unit goes here after approval