Skip to main content
An SLO is a target for how often a service must work — “99.9% of requests succeed over 30 days”. The gap between that and 100% is your error budget: the amount of failure you have agreed is acceptable.
Before you start. You need telemetry from the service you are setting an objective on. Creating an SLO requires the Editor role.

​
Why an SLO rather than an alert

A threshold alert fires whenever the number is bad right now. That is correct and exhausting: a 30-second blip at 3am pages someone for something that consumed a fraction of a percent of the month’s budget.
An error budget converts “is it bad” into “does it matter”. Two minutes of failure and two hours of failure both breach a threshold. Only one of them meaningfully spends a monthly budget, and only one should wake someone.

​
Defining one

1

Choose what counts as good

Usually requests that did not error, or that completed inside a latency bound. This is the decision that determines whether the SLO means anything — an objective on a metric nobody experiences is a number, not a target.
2

Choose the target and window

99.9% over 30 days is the common starting point. A rolling window is what you want unless you have a contractual calendar month.
3

Let the product suggest one

aiAxonIQ generates SLO suggestions from observed behaviour, which you accept or dismiss. A suggestion derived from what a service actually does is a far better starting point than a number chosen because it has three nines in it.
Do not set 99.99% because it sounds serious. Each nine costs roughly ten times the engineering effort of the last, and an objective nobody can meet is ignored within a month. Start at what you already achieve, then tighten.

​
Burn rate

Burn rate is how fast you are consuming the budget relative to the rate that would exactly exhaust it over the window. A burn rate of 1 spends the whole budget precisely at the end; a burn rate of 14 spends it in about two days.
Alert on burn rate, not on the objective being breached. By the time the objective is breached, the month is already spent. Burn rate is what gives you warning while it is still possible to act.
A burn-rate alert rule fires when consumption exceeds a rate you choose. See Alerting.

​
Forecasting

An SLO carries a forecast of where the budget is heading at the current rate. This is what turns “we are at 60% consumed on day 12” into “we exhaust on day 19 unless something changes”.

​
Error budget policies

A policy records what you have agreed to do at each level of consumption — freeze risky deploys at 75%, stop feature work at 90%.
The value is that it is agreed in advance. Deciding whether to halt a release during the incident that prompted the question is a conversation nobody wins. Written down beforehand, it is a rule rather than an argument.

​
Gating a deployment

An SLO can be checked programmatically, which lets a deployment pipeline ask “is there budget for this release?” and stop if there is not.
Fail the check open unless you have thought about it. A gate that blocks every deploy when the SLO service is unreachable turns a telemetry problem into a delivery outage. Decide which failure you prefer before wiring the gate into a pipeline that people depend on.
See the SLOs section of the API reference.

​
A common mistake

An SLO measured on a signal your users do not experience is worse than no SLO. CPU utilisation, queue depth and internal retry counts all make satisfying-looking objectives that can be perfectly green while every request fails.Measure what a user would notice: did the request succeed, and was it fast enough.

​
Next

Alerting

Burn-rate rules and the comparator that silently never fires.

Exploring metrics

The signals an objective is measured on.

Synthetic monitoring

Availability measured from outside your network.