In my research, I have found two conflicting definitions of 'availability' as it relates to software engineering and architecture. According to [1]:

"The availability of a system can be calculated as the probability that it will provide the specified services within required bounds over a specified time interval. When referring to hardware, there is a well-known expression used to derive steady-state availability:


where MTBF refers to the mean time between failures and MTTR refers to the mean time to repair. In the software world, this formula should be interpreted to mean that when thinking about availability, you should think about what will make your system fail, how likely that is to occur, and that there will be some time required to repair it."

However according to [2]:

"Availability is normally expressed as a ratio or percentage of the time that the service or service component is actually available for use by the customer to the agreed time that the service should be available. Availability is a combination of maturity (which reflect the frequency of failure), fault tolerance, and recoverability (which reflects the length of downtime following each failure). This concerns the start and finish (execution) of the application, the processing at the correct times and in the correct order, the execution of incidental processing, the opening times of online processing, and the storage period of files."

So which is correct? Source 1 is actually endorsed under the architecture section of the IEEE SWEBOK v3, so it has to be considered canonical. However, the ISO/IEEE standard is also canonical. So is availability calculated using the mean time to failure over the mean time to failure plus the mean time to repair? or a simple ratio of uptime versus agreed/target uptime?

1 - Bass, Len, et al. “Understanding Quality Attributes” Software Architecture in Practice. Third ed., Pearson Education, Inc., 2012. p. 98

2 - ISO/IEC/IEEE 24765:2017(E) 3.313 "availability"

There is a small incongruity between the definitions.

To give an example of how these two definitions can differ, consider a hypothetical company which takes down it’s servers for 8 hours every Tuesday in order to do maintenance which is accounted for in their SLA. Otherwise the system is supposed to be up.

7 days in a week * 24 Hours in a day * 60 Minutes in an Hour = 10080 minutes a week

8 Hours of downtime * 60 Minutes in an Hour = 480 minutes.

10080 – 480 = 9600.

The company promises 9600 minutes of uptime a week.

However in addition to the scheduled downtime the system occasionally crashes. Assume it crashes 20 times a week and takes 4.81 minutes to restart each time.

(24x7) MTBF = 10080 minutes a week / 20 crashes a week = 504 MTBF in minutes

(SLA) MTBF = 9600 minutes a week / 20 crashes a week = 480 MTBF in minutes

504/ (504+4.81) = ~0.99054656944 = ~99.0547%

480/ (480+4.81) = ~0.99007858748 = ~99.0079%

However using the second formula its based on AGREED uptime is a simple percentage of uptime versus downtime.

20 crashes a week * 4.81 minutes = 96.2 minutes of downtime.

(9600-96.2)/9600 = ~0.98997916666 = ~98.9979% uptime

So imagine a client or customer sues the provider saying they promised “2 nines” of uptime in the SLA, while arguing using the latter definition that they only are providing one nine of uptime.

I’ll agree this is an unlikely edge case that becomes even less likely if we calculate MTBF to include scheduled downtime (which it usually doesn’t) but one could imagine a legal case (ex: breach of SLA) hinging upon this.

  • 2
    They just seem like two different ways of quantifying the same concept of "availability". Software generally is put to so many different uses in different circumstances that it would be impossible to say any particular measure of availability was the correct one - there are probably many more kinds of availability measure than just these two mentioned.
    – Steve
    Commented Oct 14, 2022 at 15:29
  • surely you calc of MTBF should only be based on time the app is actually running? ie say i use my app which crashes every single time i run it and takes an hour to "fix", but i only run it once a year....
    – Ewan
    Commented Oct 14, 2022 at 17:09
  • @Ewan yes, which is the second formula using the SLA based MTBF of 480 minutes, which still doesn't agree with the other definition. I'll admit these numbers are extremely small. I used google search built in calculator for these quick calculations so perhaps there's a chance that there's some precision/floating point/numerical issues messing with these figures. I double checked the calculations using wolfram alpha and it appears to be the same. Commented Oct 14, 2022 at 17:19
  • is it because you arent accounting for the last period where the app is up but hasnt crashed yet?
    – Ewan
    Commented Oct 14, 2022 at 18:00
  • I don't understand why 10080 appears in any of your calculations. You don't get credit for being up outside up time in either system. Commented Oct 14, 2022 at 20:25

1 Answer 1


They are both correct. They just approach the same concept differently. The inputs are different. Why? Because you can calculate the same thing differently.

Starting with 1:


MTBF refers to the mean time between failures and MTTR refers to the mean time to repair.

Think of the same numbers a little differently:

  • MTBF is time available, on average.
  • MTBF + MTTR is the time it's supposed to be available, on average.

Divide one by the other and the "on average" part cancels out and you're left with:

time available / time supposed to be available

Which is what 2 was on about anyway.

If you'd like to be further confused by these different ways of thinking about probability I suggest you read up on Bayesian probability.=

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.