Before writing a single Prometheus rule, you need to understand what you are measuring and why. SLI and SLO are two related but distinct concepts — confusing them is the first source of errors in any reliability programme.
What is an SLI?
A Service Level Indicator is a quantitative measurement of one aspect of your service's behaviour. It is not an alert. It is not a dashboard. It is a ratio: good events / total events, expressed as a percentage. 99.3% of HTTP requests returned a success code. 97.2% of requests were served in under 200 ms. Those are SLIs. Server uptime, queue depth, and CPU usage are not — they are internal signals, not measurements of service delivered.
What is an SLO?
A Service Level Objective is a target set on an SLI, measured over a defined time window. "99.9% of HTTP requests return a success code over the trailing 28 days" is a complete SLO. It contains three inseparable elements: the SLI (success ratio), the target (99.9%), and the window (28 days). Remove any one of the three and you no longer have an SLO — you have a vague intention.
The relationship between the two
The SLI measures. The SLO decides. Your SLI tells you where you stand. Your SLO tells you whether that is acceptable. Without a target, a measurement is useless. Without a measurement, a target is noise. What connects them in practice is the error budget — the margin your SLO grants you. A 99.9% SLO over 30 days means you can afford exactly 43.2 minutes of complete outage this month. Not more, not less.
How to pick a good SLI?
A good SLI measures something your user feels directly. The latency of an internal SQL query is not an SLI — it is a symptom. The ratio of 2xx responses on your API is one. The rule is simple: if the user cannot tell the difference between 100% and 99% on a given metric, it is not the right SLI. For HTTP services, start with availability (success rate) or latency (fraction of requests below threshold). For data pipelines, freshness or coverage are often more meaningful.
How to set a realistic SLO?
Start by measuring. Look at what your service actually delivered over the past 30 days — that is your baseline. Then aim slightly below it. A 99.9% SLO for a service delivering 98.5% is an untenable promise. A 98% SLO for that same service is honest and achievable. You tighten it once you have actually improved. The order matters: measure first, target second. Never the other way round.
Three common mistakes
- Targeting 100% — it makes the error budget zero and the SLO meaningless. The generator explicitly rejects this value.
- Confusing SLO and SLA — the SLO is an internal objective. The SLA is a contractual commitment with penalties. The SLO must always be stricter than the SLA; otherwise your contract forces you to page before you have had time to react.
- Tracking too many things at once — start with a single SLI per service. Two conflicting SLOs are worth less than one well-calibrated one.
Related articles
Try the simulator →
SLO Simulator →