What is the difference between an SLI and an SLO?

An SLI is the actual measured metric, such as 99.95% of requests succeeding. An SLO is the target you set for that metric, such as staying at or above 99.9%. The SLI tells you where you are; the SLO tells you where you want to be.

What are common examples of SLIs?

The most common are availability (percentage of successful requests or uptime), latency (the share of responses under a threshold such as 300 ms), and error rate (the percentage of failed requests). Good SLIs reflect what users experience rather than internal server metrics.

How is an SLI usually calculated?

Most SLIs are expressed as the ratio of "good" events to total events over a time window, multiplied by 100. For example, an availability SLI is successful requests divided by total requests, which keeps the value between 0% and 100%.

How many SLIs should a service track?

Most teams keep it to a small handful per service, typically one each for availability, latency, and error rate, so the signals stay meaningful and tied to what users feel. Tracking too many SLIs dilutes focus and makes it harder to agree on what healthy means. Start with the one or two metrics a user would notice first, then add more only when they drive a real decision.

What Is an SLI (Service Level Indicator)?

Reviewed by Ionut Caval · Updated June 2026

A Service Level Indicator (SLI) is the specific, measured metric that quantifies a service level, such as the percentage of successful requests, the uptime percentage, or the share of responses served under a latency threshold. It is the raw number you compare against a target.

An SLI is usually expressed as a ratio of good events to total events, which keeps it between 0% and 100% and easy to reason about. For example, an availability SLI might be successful requests divided by total requests, and a latency SLI might be the percentage of requests answered in under 300 ms. The closer an SLI maps to something a user can feel, the more useful it is.

SLI vs SLO vs SLA

These three terms are layered. The SLI is the measurement, the SLO is the internal target for that measurement, and the SLA is the customer-facing promise with consequences if it is missed. In short:

SLI: what you measure (for example, 99.95% of requests succeeded last month).
SLO: the goal for that SLI (for example, keep success rate at or above 99.9%).
SLA: the contractual version of the goal, often with service credits attached.

You always need an SLI first, because an SLO or SLA without a defined measurement is just a number with no way to check it.

A worked example

Suppose your uptime SLI for a month is 99.9%. That single figure already tells you a lot: 99.9% over a 30-day month allows roughly 43 minutes of downtime, while 99.99% would allow only about 4.3 minutes. The blog post what 99.9% uptime actually means breaks the "nines" down in full. If your SLO is 99.9% and the SLI comes in at 99.97%, you are comfortably inside target; if it comes in at 99.7%, you have missed the SLO and may be at risk of breaching an SLA.

Uptime measured from outside your own infrastructure is one of the most common SLIs, because it captures the experience a visitor actually has rather than the server's view of itself. Pulsetic's SLA monitoring records exactly this kind of indicator continuously, so the number behind your SLO or SLA is always backed by real measurement.

Frequently asked questions

What is the difference between an SLI and an SLO?

An SLI is the actual measured metric, such as 99.95% of requests succeeding. An SLO is the target you set for that metric, such as staying at or above 99.9%. The SLI tells you where you are; the SLO tells you where you want to be.
What are common examples of SLIs?

The most common are availability (percentage of successful requests or uptime), latency (the share of responses under a threshold such as 300 ms), and error rate (the percentage of failed requests). Good SLIs reflect what users experience rather than internal server metrics.
How is an SLI usually calculated?

Most SLIs are expressed as the ratio of "good" events to total events over a time window, multiplied by 100. For example, an availability SLI is successful requests divided by total requests, which keeps the value between 0% and 100%.
How many SLIs should a service track?

Most teams keep it to a small handful per service, typically one each for availability, latency, and error rate, so the signals stay meaningful and tied to what users feel. Tracking too many SLIs dilutes focus and makes it harder to agree on what healthy means. Start with the one or two metrics a user would notice first, then add more only when they drive a real decision.

Put these metrics to work. Monitor your site free.

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed