When we're thinking about the reliability of the service from the perspective of its users, we usually find that any number of specific root causes collapse down to a small set of observable symptoms. We gave a couple of examples of this at the beginning of the previous lesson. There are a few common types of SLIs that quantify these observable symptoms. Choosing from this list, can make the process deciding which aspects of your particular user journey to measure significantly easier. We categorize user journeys by the interaction user undertakes while on the journey. If your service is responding to a user's request, then you almost certainly want to measure how fast those responses are and how many of them are unsuccessful. If you have mechanisms that can degrade the quality of the response a user receives to alleviate excess load on your service, measuring how often this occurs is also a good idea. If the user is expecting some data to be crunched on their behalf either explicitly or implicitly, then they will probably have expectations that processing completes within a reasonable time frame and processes all the data it should have without errors. You can quantify these expectations by measuring the freshness and correctness of the processed data and the coverage and throughput of the pipeline doing the processing. Lastly, if the user is giving you some of their data to store and they have expectations that they will be able to retrieve that data again, you may want to measure the durability of your storage layer. In practice, this turns out to be less useful than you might hope because the risks to stored data are more likely to come from rare but devastating events like a complete outage of an entire data center or accidental corruption due to a software bug. Events like these will blow many multiples of any error budget you might have, but otherwise it's unlikely your SLI will budge from a 100 percent. We'll be referring to these dimensions of reliability like availability latency, et cetera, as SLI types from now on. Our SLI menu gives you guidelines for what types of SLI you are likely to want to measure for a given user journey. These are just guidelines. As we get further into the details, you'll notice that the high level taxonomy we describe here doesn't cover everything, and some types of SLIs are useful for quantifying more than one class of interaction. When you map a set of SLI types onto your specific user journey, resulting SLI specification should describe in high level terms events you want to measure. In the next few videos, we'll talk about these mappings for the common SLI types, and in the next module, we'll learn how to refine these SLI specifications into concrete SLI implementations. By setting down explicitly, what criteria makes an event valid for inclusion in the SLI? What makes an event good? And how and where events are measured?