---
title: "SLO and error budget design | Skills We Assign For | Azendo"
description: "SLOs and error budgets — turning reliability into a number teams can spend, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/slo-and-error-budget-design/"
---

[Skills](https://azendo.co/skills/) Observability 

# SLO and error budget design.

A service level objective states a target for a measurable aspect of reliability over a window. The error budget is what remains — the amount of unreliability the objective permits — and it turns reliability from an argument into arithmetic.

## Where SLO and error budget design fits on a long engagement.

The useful move is making unreliability a budget rather than a failure. If the objective is 99.9% over thirty days, roughly forty-three minutes of failure is permitted, and the question stops being "should we have had an incident" and becomes "how much budget have we spent". That reframing is what makes the conversation between delivery speed and stability tractable.

Objectives only work if they are set from what users need rather than from what sounds impressive. A 99.99% target on a service where users would not notice 99.5% costs a great deal and buys nothing, and the engineering effort it consumes is taken directly from work that would matter.

## What an assigned team does with SLO and error budget design.

The budget has to have consequences or it is decoration. A team that exhausts its budget and continues shipping features has an objective nobody believes, and the next one will be ignored too.

Agreeing those consequences is a decision for you; holding the measurement and reporting honestly is what we answer for, which is the division set out in [how an assignment runs](https://azendo.co/how-it-works/).

## What we use SLO and error budget design for.

* Reliability argued with numbers Budget spend replacing opinion in the trade-off between shipping and stabilising.
* Targets set from user need Objectives derived from what users actually notice rather than from a round number.
* Alerts tied to budget burn Paging on the rate of budget consumption, which reduces noise dramatically.

## How SLO and error budget design capacity is assigned.

Reliability engineering is assigned under [devops managed services](https://azendo.co/services/cloud-and-devops/), with objectives derived from your users rather than proposed as a standard number.

## Roles we assign SLO and error budget design for

* [Site Reliability Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/site-reliability-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in observability

* [Datadog — skill we assign for](https://azendo.co/skills/datadog/)
* [New Relic — skill we assign for](https://azendo.co/skills/new-relic/)
* [Grafana — skill we assign for](https://azendo.co/skills/grafana/)
* [APM — skill we assign for](https://azendo.co/skills/apm/)
* [distributed tracing — skill we assign for](https://azendo.co/skills/distributed-tracing/)
* [Database query profiling — skill we assign for](https://azendo.co/skills/database-query-profiling/)
* [Prometheus — skill we assign for](https://azendo.co/skills/prometheus/)
* [OpenTelemetry — skill we assign for](https://azendo.co/skills/opentelemetry/)

## Tell us what your roadmap needs SLO and error budget design for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)