SRE in Practice | Day 8: Availability Calculations - The Maths of Nines

What you will learn

• How to calculate availability by time and by requests
• The maths of the nines, per 30 days and per year
• How series and parallel designs change the result, and where redundancy stops helping
• Six hands-on labs with expected output

Safety first: All commands are read-only or touch only files under /tmp/sre-lab that you create. Run them on a system you are authorized to use. Never run cleanup or deletion commands on real data until you have reviewed a dry run, and do not paste logs containing credentials or customer data into public posts.

1. The maths of availability

Availability is the share of time, or the share of requests, in which a service works. Because SLOs are usually written as percentages, you need to be comfortable turning percentages into minutes and back.

Time-based: availability = uptime / (uptime + downtime)

Request-based: availability = good requests / total requests

From failure data: availability = MTBF / (MTBF + MTTR)

Time-based and request-based availability can give very different answers for the same incident. A short outage at midnight affects few requests but counts as full downtime in a time-based measure. Whichever you choose, write it down. Day 10 explains MTBF and MTTR.

2. The nines

People describe availability by its "nines". Each extra nine cuts the allowed downtime by a factor of ten.

Going from three to four nines means detecting and fixing problems in minutes, with little or no human delay. That usually requires automation, redundancy, and a lot of engineering. Choose the number users actually need.

3. Combining components

Real services depend on other components. The way they are connected changes the maths.

A caution about redundancy: The parallel formula assumes the copies fail independently. Two servers behind the same load balancer, in the same zone, using the same database do not fail independently. Redundancy only helps against the failures it is actually separated from.

4. A production-style example

This is an illustrative scenario. A checkout request passes through four components in series:

Multiplying gives about 99.79% end to end, lower than the weakest component (99.9%). A team that wanted a 99.9% SLO for this journey would not reach it by monitoring alone. They would need to improve the weakest links, add redundancy where failures are independent, or remove a dependency. The lab calculates this.

5. Hands-on labs

Safety notes: All commands are read-only or touch only files under /tmp/sre-lab that you create. Run them on a system you are authorized to use. Never run cleanup or deletion commands on real data until you have reviewed a dry run, and do not paste logs containing credentials or customer data into public posts.

Setup

mkdir -p /tmp/sre-lab && cd /tmp/sre-lab

Lab 1: build a nines table

This awk program converts an availability target into allowed downtime for 30 days and for a year.

awk 'function fmt(s){ if (s>=3600) return sprintf("%dh %02dm", s/3600, (s%3600)/60)
                      if (s>=60)   return sprintf("%.1f min", s/60)
                      return sprintf("%.1f s", s) }
BEGIN{ n=split("99 99.9 99.95 99.99 99.999", a, " ")
       printf "%-9s %-14s %-14s\n", "SLO", "per 30 days", "per year"
       for(i=1;i<=n;i++){ f=(100-a[i])/100
         printf "%-9s %-14s %-14s\n", a[i]"%", fmt(30*86400*f), fmt(365*86400*f) } }'

Expected output

SLO       per 30 days    per year
99%       7h 12m         87h 36m
99.9%     43.2 min       8h 45m
99.95%    21.6 min       4h 22m
99.99%    4.3 min        52.6 min
99.999%   25.9 s         5.3 min

The values match the table above, rounded or truncated for display (for example 8 h 45.6 min prints as 8h 45m). Try changing the list of targets to your own SLOs.

Lab 2: availability of components in series

awk 'BEGIN{n=split("0.9999 0.9995 0.999 0.9995", a, " "); p=1
  for(i=1;i<=n;i++) p*=a[i]
  printf "end-to-end = %.4f%%  (weakest part: 99.9000%%)\n", p*100
  printf "allowed downtime at that level: %.1f min per 30 days\n", 30*24*60*(1-p)}'

Expected output

end-to-end = 99.7901%  (weakest part: 99.9000%)
allowed downtime at that level: 90.7 min per 30 days

Four individually good components produce an end-to-end result of about 99.79%, or roughly 90.7 minutes of downtime in 30 days, more than twice what a 99.9% target allows (43.2 minutes).

Lab 3: availability of redundant instances in parallel

awk 'BEGIN{a=0.999
  for(n=1;n<=3;n++)
    printf "%d instance(s) in parallel: %.8f%%\n", n, (1-(1-a)^n)*100}'

Expected output

1 instance(s) in parallel: 99.90000000%
2 instance(s) in parallel: 99.99990000%
3 instance(s) in parallel: 99.99999990%

Two independent 99.9% instances give 99.9999% in theory. In practice shared failures (the same zone, load balancer, database, or bad deployment) limit the gain. Treat these numbers as an upper bound.

Lab 4: monthly availability from an incident list

cat > incidents_min.csv <<'EOF'
date,minutes_down
2026-10-03,12
2026-10-11,7
2026-10-19,18
EOF

awk -F, 'NR>1{d+=$2}
  END{total=30*24*60
      printf "downtime=%d min  availability=%.4f%%  ", d, (total-d)/total*100
      printf "budget(99.9%%)=%.1f min  left=%.1f min\n",
             total*0.001, total*0.001-d}' incidents_min.csv

Expected output

downtime=37 min  availability=99.9144%  budget(99.9%)=43.2 min  left=6.2 min

Three short incidents add up to 37 minutes. The month is still above 99.9% (99.9144%) but only 6.2 minutes of allowance is left. Tomorrow we call that allowance the error budget.

Lab 5: request-based versus time-based availability

Create the sample log from Days 5 to 7 (use the same generator), then calculate availability both ways. Here a minute counts as bad when more than 1% of its requests fail.

awk 'BEGIN{
  for(i=1;i<=6000;i++){
    m=int((i-1)/2000); s=200
    if(i%200==0) s=500
    else if(m==1 && i%20==0) s=500
    else if(i%97==0) s=404
    t=0.05+(i%20)*0.01
    if(i%50==0) t=1.5
    ts=sprintf("[01/Nov/2026:10:%02d:00 +0000]", m)
    printf "10.0.0.%d - - %s \"GET /api HTTP/1.1\" %d 512 %.3f\n",
           (i%250)+1, ts, s, t
  }}' > access.log

awk '{t++; if ($9>=500) e++}
     END{printf "request-based availability=%.2f%%\n", (t-e)/t*100}' access.log
awk '{split($4,a,":"); m=a[3]; t[m]++; if ($9>=500) e[m]++}
 END{for(m in t){ if (e[m]/t[m] > 0.01) bad++; n++ }
     printf "bad minutes=%d of %d -> time-based availability=%.2f%%\n",
            bad, n, (n-bad)/n*100}' access.log

Expected output

request-based availability=98.00%
bad minutes=1 of 3 -> time-based availability=66.67%

The same data gives 98.00% by requests and 66.67% by time. Neither is wrong, they answer different questions. Pick the definition that matches how users experience the service, and apply it consistently.

Lab 6 (worksheet): your own dependency chain

Multiply or combine them as in Labs 2 and 3. Compare the result with the SLO you would like to promise.

6. Common mistakes

• Mixing up percentages and minutes, especially for 99.9% versus 99.99%
• Forgetting that dependencies multiply, so the whole is less than the parts
• Assuming redundancy removes failures that the copies share
• Quoting availability without saying whether it is time-based or request-based
• Promising a number that your dependencies make impossible
• Using a 365-day year for monthly calculations, or the reverse, without saying so

7. Quick check: test yourself

• How many minutes of downtime does 99.95% allow in 30 days?
• Two components in series have 99.9% and 99.5% availability. What is the combined value?
• Why is the parallel formula an upper bound in practice?
• How can request-based and time-based availability differ for the same incident?
• What does going from 99.9% to 99.99% usually require?

Suggested answers: 21.6 minutes; 0.999 x 0.995 = 99.40%; copies often share failures such as the same zone or database; short outages hit few requests but count as full downtime by time; much faster detection and recovery, redundancy, and automation.

Glossary

The first ten days at a glance

Your turn: Which dependency in your service has the lowest availability, and what would improve it?

Coming next, Day 9: error budgets and burn rates.

Follow @srilakshmi-t  for the daily posts in this 30-day journey.