If you are a DevOps engineer then you might have heard of the terms SLI, SLA, and  SLO. These are being used as part of the daily job.  An optimum level of performance is very important for software which can be monitored by setting thresholds or targets and if in the case of software, latency reaches or exceeds these thresholds then it may impact the consumer experience. Application metrics like latency, uptime, throughput, error count and mean recovery time, etc are monitored by DevOps engineers or SREs by setting benchmarks for these metrics. SLI, SLA, and SLO come into the picture for these tasks. Let us briefly explain each term one by one below.  Service Level Indicator (SLI):  Service behaviour can be directly measured with the help Service Level Indicator. Performance metrics like latency and the error rate which indicate overall performance can be easily measured with SLI. It can be easily understood with the help of an example like in a span of one month, how many successful requests are there out of the total requests received by an application. Let us suppose there is only 1 failed request out of 100k requests received then the SLI would be 99.99% uptime.  Service Level Agreement (SLA):  SLA as its name says acts as an agreement between the service provider and the service receiver(user). SLAs commit to the application availability and can include responsiveness to bugs and incidents. SLA breakage leads to penalties which can be in the form of service subscription credit or refund. In Today’s world, most business uses cloud-based Paas, IaaS, and SaaS. We can take an example of an online payment that may require hitting remote servers multiple times. And if in case the online services go down suddenly then it will halt that transaction. So, SLA needs to be implemented to ensure application availability with minimum failed requests so that specific standards can be maintained between both parties.  As the application behaviour can be easily tracked by SLI, an engineer can set an SLA after getting an idea of the behaviour. SLA sets an objective of application availability like not more than 10 failed requests out of 100k total requests to ensure 99.999% availability and if failed requests exceed this threshold, then it may lead to a penalty according to the contract signed.  Service Level Objective (SLO):  SLO (Service Level Objective) as its name suggests is used to set a performance objective or target similar to SLA. SLOs are implemented to avoid breakage of SLAs to ensure users will never report any performance issues. We can take the example of SLA ensuring 99.999% availability i.e., 10 failed requests out of 100k total requests. To avoid breakage of this SLA, we can set an SLO of 99.995% availability i.e., 5 failed attempts out of 100k total requests and if the application failed to meet this objective, then some improvement needs to be done in application design and search for loopholes in the system which is impacting performance.