Service quality and availability
Objectives
By the end of the lesson, you can say why the quality of a web service is more than the state of the server, you can calculate how much downtime an availability target allows, and you can tell the SLI, the SLO, and the SLA apart.
Why is it not enough to say "the server works"?
When someone says "the website was bad", they often compress several distinct problems into one sentence. The page may not have opened. It may have opened but stopped at payment. It may be that the home page appeared quickly, but a visitor using a screen reader could not go further. The quality of a service is therefore not a single metric but a set of interrelated properties.
It includes functional correctness (does the system do what it promises?), performance (9.4), usability and accessibility (chapter 9), security (chapter 8), and privacy (9.6). Reliability expresses how predictably the system behaves over time, not only at a single successful attempt.
This approach helps avoid talking only about the state of the server. A "green" server does not guarantee a good experience: the server can be reachable while an external payment provider is down; the page can return a 200 response while a JavaScript error makes the cart button not work (2.4: HTTP success is not business success); or the system can be fast from Budapest but unusable on a slow mobile network.
flowchart LR
U[User task] --> K{Does it succeed?}
K -->|yes| H[Correct result]
K -->|no| V[Error and recovery]
H --> M[Measuring service quality]
V --> M
Availability: is the service reachable?
Availability describes in what proportion of the examined period the service is usable as intended. "Usable" and "as intended" are the key words: it is not enough that a machine responds on the network. An online study system is available if the student can log in, can look at their subjects, and can carry out the necessary operations. Google's SRE book (Site Reliability Engineering, the practice of reliability engineering) also measures availability as the proportion of well-formed requests that succeed.
Availability is often given as a percentage. What it means in practice we calculated for a thirty-day month:
| Target |
Allowed downtime / month |
Note |
| 90% |
72 hours (4,320 minutes) |
a multi-day outage |
| 99% |
7.2 hours (432 minutes) |
a working day's worth of downtime |
| 99.9% |
43.2 minutes |
"three nines" |
| 99.99% |
4.3 minutes (259 s) |
"four nines" |
More "nines" is therefore not marketing: it means an ever stricter expectation, and it is ever more expensive too, because little downtime leaves little human reaction time. The availability percentage, however, does not say when the outage happened. A five-minute fault at three in the morning has a different consequence from the same fault when course registration opens.
It is also a question what counts as an outage. If the public home page works but after login nobody can save, the service is partially down. If only the recommender does not work but enrolment is possible, that is also a fault, but of a different weight. Good quality targets therefore start from the critical user journeys: login, search, enrolment, upload, administration.
Reliability, resilience, recovery
Three related but not identical concepts:
- reliability: the system is expected to work correctly over a longer time;
- resilience: even on a fault it strives to maintain or meaningfully limit the important service;
- recoverability: how quickly and safely the system returns to the proper state.
Imagine a web shop. If the recommender module is faulty, a resilient system still shows the products and allows purchase, and only honestly signals in the place of the recommendations that this function is temporarily unavailable. If, however, the fault of the recommender leaves the entire home page empty, the system has coupled the less important and the vital functions too tightly. The goal is not that nothing can go wrong, but that the impact of a fault should not be larger than absolutely necessary.
Faults are not exceptional events: networks slow down, external services are late, configurations can be wrong, people make mistakes. Quality thinking is built not on "eternal flawlessness" but on the system recognizing, handling, and communicating the fault understandably (10.2).
SLI, SLO, and SLA: three similar abbreviations, three different roles
According to Google's SRE book:
- The SLI (Service Level Indicator) is "a carefully defined quantitative measure of some aspect of the level of service that is provided". Typical SLIs are request latency, error rate, throughput (requests per second), and availability. An SLI is a measurement, not a promise.
- The SLO (Service Level Objective) is the target value or target range of an SLI. For example "the proportion of successful payments is at least 99.95% per month", or "95% of searches respond within two seconds". A good SLO is concrete: it says what we measure, with what threshold, and in what time window.
- The SLA (Service Level Agreement) is a contract with the users which has a consequence if the commitment is not met. The SRE book's useful test: ask what happens if it is not met; if there is no stated consequence, it is probably an SLO.
One sentence to remember: the SLI says what happened; the SLO says what we would like to achieve; the SLA says what we commit to toward others. It is not good practice if the external contractual minimum is the same as the internal target: then the smallest deviation is a breach of contract, and there is no room to notice a worsening trend. That is why the SLA is generally more cautious than the internal SLO.
Error budget
A 100% target is not realistic, and it slows innovation too. The SRE book therefore recommends an error budget: from the SLO it follows what proportion of errors is allowed, and this budget is tracked over days and weeks. If the remaining part of the budget is large, new versions can be released more boldly; if it has run out, stability takes priority. The error budget of a 99.9% monthly target is 43.2 minutes of downtime.
Percentile, not average
According to the SRE book, averages hide the slow exceptions; the high percentiles (99th, 99.9th) show the plausible worst case, the median (50th) the typical one. We tried a ten-element sample: nine requests of 100 ms and one of 10 seconds.
mean: 1090 ms; median: 100 ms; max: 10000 ms
The mean (1.09 s) seems acceptable, but for the tenth user the service was clearly bad. That is why a good part of SLIs is built on percentiles (for example "95% of requests within 2 seconds").
Worked example: the opening of course registration in Kurzuspont
Course registration opens on Monday at 10:00. The operator checks only that the opening page responds. That is too little: the student has to log in, find the course, and save the enrolment. If the first two steps work but saving gives an error because of a timeout, from the user's point of view the critical service is not available.
| Element |
In Kurzuspont |
| Critical path |
login → searching for the course → saving the enrolment |
| SLI |
What percentage of initiated enrolments finish successfully, and the response time of saving at p95 |
| SLO |
In the two hours after opening, at least 99.5% of enrolments are successful; the p95 response time of saving is at most 2 s |
| SLA |
The contract between the university and the provider: more cautious, for example 99.0% monthly, with a consequence (a fee credit) |
| Error budget |
With the 99.5% target, 0.5% of the opening requests may fail; if this runs out sooner, we stop non-urgent changes |
It does not follow that every error in the remaining 0.5% is acceptable: the causes of the errors must still be investigated. The metric only helps so that quality is judged not from anecdotes or a single server signal.
Common misconceptions
| Statement |
Clarification |
| "100% availability is a realistic principle." |
In the long run zero downtime is extremely expensive; the right question is how much downtime of which function causes how much damage. |
| "If the server sends 200 OK, everything is fine." |
The HTTP status is a communication signal; the business operation behind it can be faulty. |
| "High availability equals a good user experience." |
A slow or hard-to-use service can be available and still fail. |
| "An SLA is a technical metric." |
It is a contractual commitment; it may contain a metric, but it is not the same as the measurement or the internal target. |
| "The average response time describes quality well." |
The average hides the slow but real cases. |
In brief
- Quality is a set of several properties; a "green server" is not yet a good service.
- The availability percentage must be translated into downtime: 99.9% ≈ 43.2 min/month, 99.99% ≈ 4.3 min/month.
- SLI = metric, SLO = internal target, SLA = contractual commitment with a consequence.
- The error budget says how many errors fit in the target; 100% is not a realistic target.
- Percentile instead of average, and measure on the critical user journeys.
Review questions
- How much downtime per month does a 99.95% target allow?
- What is the difference between an SLI and an SLO?
- Why is the SLA more cautious than the internal SLO?
- Why is the average response time misleading?
Learning resources
Service quality and availability
Objectives
By the end of the lesson, you can say why the quality of a web service is more than the state of the server, you can calculate how much downtime an availability target allows, and you can tell the SLI, the SLO, and the SLA apart.
Why is it not enough to say "the server works"?
When someone says "the website was bad", they often compress several distinct problems into one sentence. The page may not have opened. It may have opened but stopped at payment. It may be that the home page appeared quickly, but a visitor using a screen reader could not go further. The quality of a service is therefore not a single metric but a set of interrelated properties.
It includes functional correctness (does the system do what it promises?), performance (9.4), usability and accessibility (chapter 9), security (chapter 8), and privacy (9.6). Reliability expresses how predictably the system behaves over time, not only at a single successful attempt.
This approach helps avoid talking only about the state of the server. A "green" server does not guarantee a good experience: the server can be reachable while an external payment provider is down; the page can return a
200response while a JavaScript error makes the cart button not work (2.4: HTTP success is not business success); or the system can be fast from Budapest but unusable on a slow mobile network.flowchart LR U[User task] --> K{Does it succeed?} K -->|yes| H[Correct result] K -->|no| V[Error and recovery] H --> M[Measuring service quality] V --> MAvailability: is the service reachable?
Availability describes in what proportion of the examined period the service is usable as intended. "Usable" and "as intended" are the key words: it is not enough that a machine responds on the network. An online study system is available if the student can log in, can look at their subjects, and can carry out the necessary operations. Google's SRE book (Site Reliability Engineering, the practice of reliability engineering) also measures availability as the proportion of well-formed requests that succeed.
Availability is often given as a percentage. What it means in practice we calculated for a thirty-day month:
More "nines" is therefore not marketing: it means an ever stricter expectation, and it is ever more expensive too, because little downtime leaves little human reaction time. The availability percentage, however, does not say when the outage happened. A five-minute fault at three in the morning has a different consequence from the same fault when course registration opens.
It is also a question what counts as an outage. If the public home page works but after login nobody can save, the service is partially down. If only the recommender does not work but enrolment is possible, that is also a fault, but of a different weight. Good quality targets therefore start from the critical user journeys: login, search, enrolment, upload, administration.
Reliability, resilience, recovery
Three related but not identical concepts:
Imagine a web shop. If the recommender module is faulty, a resilient system still shows the products and allows purchase, and only honestly signals in the place of the recommendations that this function is temporarily unavailable. If, however, the fault of the recommender leaves the entire home page empty, the system has coupled the less important and the vital functions too tightly. The goal is not that nothing can go wrong, but that the impact of a fault should not be larger than absolutely necessary.
Faults are not exceptional events: networks slow down, external services are late, configurations can be wrong, people make mistakes. Quality thinking is built not on "eternal flawlessness" but on the system recognizing, handling, and communicating the fault understandably (10.2).
SLI, SLO, and SLA: three similar abbreviations, three different roles
According to Google's SRE book:
One sentence to remember: the SLI says what happened; the SLO says what we would like to achieve; the SLA says what we commit to toward others. It is not good practice if the external contractual minimum is the same as the internal target: then the smallest deviation is a breach of contract, and there is no room to notice a worsening trend. That is why the SLA is generally more cautious than the internal SLO.
Error budget
A 100% target is not realistic, and it slows innovation too. The SRE book therefore recommends an error budget: from the SLO it follows what proportion of errors is allowed, and this budget is tracked over days and weeks. If the remaining part of the budget is large, new versions can be released more boldly; if it has run out, stability takes priority. The error budget of a 99.9% monthly target is 43.2 minutes of downtime.
Percentile, not average
According to the SRE book, averages hide the slow exceptions; the high percentiles (99th, 99.9th) show the plausible worst case, the median (50th) the typical one. We tried a ten-element sample: nine requests of 100 ms and one of 10 seconds.
The mean (1.09 s) seems acceptable, but for the tenth user the service was clearly bad. That is why a good part of SLIs is built on percentiles (for example "95% of requests within 2 seconds").
Worked example: the opening of course registration in Kurzuspont
Course registration opens on Monday at 10:00. The operator checks only that the opening page responds. That is too little: the student has to log in, find the course, and save the enrolment. If the first two steps work but saving gives an error because of a timeout, from the user's point of view the critical service is not available.
It does not follow that every error in the remaining 0.5% is acceptable: the causes of the errors must still be investigated. The metric only helps so that quality is judged not from anecdotes or a single server signal.
Common misconceptions
In brief
Review questions
Learning resources