Service-level agreements and availability

Take a campus course-registration API and watch it for a 30-day month, which is 720 h. During that month it is unreachable twice, for a total of 2 h. For the other 718 h it answered requests. The fraction of the month it could answer is 718 / 720 = 0.9972, or 99.72%. That fraction is the service's Availability.

The general rule only names the two pieces. Uptime is the time the application can serve requests, and Downtime is the time it cannot. Availability is the share of uptime in the total:

The denominator is simply the length of the observation period, $T$. Rearranging gives the form you will use most often, because it turns a promised availability into an allowance of failure: $D=(1-A)\times T$. For the registration API, (1 − 0.9972) × 720 h ≈ 2 h, which is exactly where we started.

Counting requests instead of hours

Large providers rarely have a clean on or off switch. A service may be up for most users while one shard fails. So they often measure availability by requests rather than by time: successful requests divided by valid requests. Google's SRE book gives a concrete case. A system that serves 2.5 million requests a day with a daily target of 99.99% may fail up to 250 of them. AWS combines both views: it measures success in windows of 1 or 5 minutes and averages the windows into a monthly uptime percentage.

Estimating availability before you have measurements

At design time there is no uptime log yet. Instead you can estimate availability from two failure statistics: the mean time between failures (MTBF) and the mean time to recover (MTTR).

Start with the most common promise in cloud marketing, 99.9%, often called “three nines”. Its unavailability is 1 − 0.999 = 0.001. Multiply that by a period and you get the Downtime it allows: 0.001 × 8760 h = 8.76 h a year, 0.001 × 720 h = 43.2 min in a 30-day month, and 0.001 × 168 h ≈ 10.1 min a week.

Now add one more nine. An Availability of 99.99% has an unavailability of 0.0001, ten times smaller, so every downtime figure shrinks tenfold: 52.56 min a year, 4.32 min a month. That is the whole rule. Google's SRE book calls each additional nine “an order of magnitude improvement”, and the cost of getting there typically rises much faster than tenfold.

The table below repeats the calculation for each common tier. Like the lecture slide, it assumes a 365-day year, a 30-day month and a 7-day week. Every cell on the slide recomputes correctly with those conventions, and the figures agree with the availability table in the Google SRE book. The last column gives the example workloads AWS associates with each tier, so you can feel what a nine buys.

What makes a number an agreement

A Service-level agreement (SLA) is where availability becomes a business promise. The vocabulary has three layers. You measure an indicator, you set an objective for it, and you sign an agreement that attaches consequences to the objective. Google's SRE book draws the line sharply: if nothing happens when the target is missed, it is an SLO, not an SLA. Azure's guidance says the same in business terms: an SLA has financial and legal implications, while SLOs are internal targets.

Read the Amazon EC2 SLA as a worked case. It promises 99.99% monthly uptime for instances spread across a region, but only 99.5% for a single instance. The gap is deliberate: one machine can fail, and only an architecture that spreads across failure domains earns the higher number. If AWS misses the regional promise, you receive a credit of 10%, 30% or 100% of that month's bill depending on how far uptime fell. You never receive compensation for your own lost business.

A request rarely touches a single service. Picture a request that first passes through Service 1, a front end promising 99.99%, and then Service 2, a database promising 99.9%. The request succeeds only if both are up at that moment. If the two fail independently, the probability that both are up is the product of their availabilities: 0.9999 × 0.999 = 0.9989001, about 99.89%.

Notice where the answer lands. It is not between the two numbers. It is below the weaker one. That result is the Compound SLA, and it holds for any chain of hard dependencies, where the failure of one stage makes the whole request fail:

The inequality follows from the arithmetic. Every $A_i$ is at most 1, and multiplying by a number at most 1 can only keep a value the same or lower it. AWS puts the consequence plainly: a workload can be no more available than any of its hard dependencies.

A shortcut and a warning about scale

When every unavailability is small, the product is close to one minus their sum. Here the unavailabilities are 0.01% and 0.1%, which add to 0.11%, giving roughly 99.89%. The exact value is 99.89001%, so the shortcut is good enough for an exam sanity check.

The shortcut also shows why long chains hurt. Five services at 99.9% each give 0.999⁵ ≈ 0.99501, about 99.50%, which is roughly 43.7 h of downtime a year against 8.76 h for one service. AWS gives a gentler version: a 99.99% system that hard depends on two other 99.99% systems lands at about 99.97%. Every microservice, managed database or edge gateway you add in series spends part of the budget.

Redundancy runs the arithmetic the other way

The fix for a weak link is to stop needing it to be up. Place independent replicas behind automatic failover so that any one of them can serve. Now the request fails only if all replicas are down at once, so you multiply the unavailabilities instead:

Two 99.9% replicas give 1 − 0.001² = 0.999999, or 99.9999%. AWS notes a quick way to see this when every component is all nines: count the nines, 3 + 3 = 6. The same idea explains why the Amazon EC2 SLA commits to only 99.5% for a single instance but 99.99% for instances spread across a region: the regional promise assumes your workload can survive the loss of any one instance. The two numbers are business commitments, not outputs of the formula.

A compound availability of 99.89% is still an abstract percentage. To plan operations you need it in minutes of Downtime. Its unavailability is 0.11%, or 0.0011, and the rule from the previous concepts does the rest.

Online calculators such as uptime.is, the tool shown on the slide, automate exactly this multiplication. They are convenient, but they hide the period convention. uptime.is uses an average Gregorian year and month (about 365.24 d and 30.44 d), so its monthly and yearly figures come out slightly larger than the hand calculation with 30 and 365 days. The table compares the three sources.

From allowance to error budget

Operations teams turn this allowance into a working tool called an error budget. Google's SRE book defines it as the gap between the SLO and the measured performance: the budget of how much unreliability is remaining in the period. While budget remains, the team ships releases and runs experiments, each of which risks a little downtime. When the budget is spent, releases pause and effort shifts to reliability. The Service-level agreement (SLA) sets the outer limit; the error budget is how the team manages its way to it.

Azure's reliability guidance shows the same thinking from the design side. In its worked example the composite of a workload's components comes to about 99.45%, roughly 4 h of downtime a month. The business then signs a 99.90% SLA anyway, consciously accepting the risk of paying credits. That gap between what the architecture supports and what the contract promises is a business decision, and it is exactly what the compound arithmetic lets you see before you sign.