Now that you know how to evaluate whether or not a service is running within SLO using SLIs, you might think you are ready to apply this to your organization. Well, not quite. It turns out that not everything is linear and we don't always want or need the same level of reliability for a service. In fact, there are many edge cases in different organizations that don't conform to a single SLO for everything. For example, the impact of outages isn't always constant over time. In the US, for Black Friday, which is the Friday after Thanksgiving and the biggest shopping day of the year, retailers might expect four times as much traffic and much more adverse publicity in the case of errors. So, they might shift from wanting a three nines available service for most of the year to something closer to four nines, which they address by temporary strategies, such as over-provisioning resources, implementing change freezes, or utilizing war rooms. Then after Black Friday is over, they will switch back to three nines availability targets. Or another example is that an outage duration can impact customer happiness. For example, having your customers experience four one hour outages, versus a single four hour outage, versus a 0.5% error rate all the time. Some customers will prefer one, some the other. But error budget impact is identical. We'll talk more about error budgets in the next module. But for now, know that error budgets are the amount of errors that are allowed to be served based on your SLOs. Perhaps not all of your users are equal. Some might not actually care about service reliability or they'll care much less than others. For example, users can be automatic bots that scrape your content and might encounter a higher number of errors because they don't behave the way that a human user does. For such edge cases, your SLOs could be a bit tricky. You might find that having a longer latency SLO for three nines of your responses is good for most of your requests, but some users might find that too slow. Or perhaps you want to make the latency shorter, however, you risk getting more errors. It is entirely reasonable to set more than one target for a latency SLO to capture the distribution more effectively. It's common to set a target for the median user and for the long tail to make sure that it doesn't get too long. Depending on your user feedback, you may have to tweak your SLOs which we'll talk about later in this section.