> ## Documentation Index > Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt > Use this file to discover all available pages before exploring further. # Service level objectives > Define an SLO, watch the error budget, alert on burn rate rather than on every blip, and gate a deployment on remaining budget. 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 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. 99.9% over 30 days is the common starting point. A rolling window is what you want unless you have a contractual calendar month. 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. | Burn rate | Meaning | Response | | :-------- | :------------------------ | :------------------ | | Under 1 | Comfortably inside budget | Nothing | | 1–2 | On track to exhaust it | Worth investigating | | 6+ | Days from exhaustion | Page someone | | 14+ | Hours from exhaustion | Page someone now | **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](/guides/alerts/overview). ## 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](/api-reference/introduction). ## 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 Burn-rate rules and the comparator that silently never fires. The signals an objective is measured on. Availability measured from outside your network.