SLOs, SLIs y error budgets: una guía práctica
Los SLO convierten metas vagas de fiabilidad en contratos medibles: cómo definir SLIs, fijar SLOs y usar error budgets para equilibrar la velocidad.

Decir que "el servicio debe ser fiable" no es algo accionable. ¿Fiable para quién? ¿Cuán fiable? ¿Qué ocurre cuando la fiabilidad empeora? Los Service Level Objectives (SLOs) responden a estas preguntas con números. Definen cuánta falta de fiabilidad es aceptable, creando un contrato medible entre tu equipo y tus usuarios.
Los tres conceptos
Service Level Indicator (SLI) — una medición cuantitativa del comportamiento del servicio. "¿Qué porcentaje de solicitudes se completan con éxito en menos de 500 ms?"
Service Level Objective (SLO) — un rango objetivo para un SLI. "El 99,9% de las solicitudes deben completarse con éxito en menos de 500 ms durante una ventana móvil de 30 días."
Error Budget — el inverso de un SLO. Si tu SLO es del 99,9%, tu error budget es del 0,1%: puedes tolerar 43 minutos de inactividad cada 30 días.
// Calculate error budget remaining
interface SLOConfig {
target: number; // e.g., 0.999 (99.9%)
windowDays: number; // e.g., 30
}
interface SLIMetrics {
totalRequests: number;
successfulRequests: number;
}
function calculateErrorBudget(config: SLOConfig, metrics: SLIMetrics) {
const currentSLI = metrics.successfulRequests / metrics.totalRequests;
const allowedFailureRate = 1 - config.target;
const allowedFailures = Math.floor(metrics.totalRequests * allowedFailureRate);
const actualFailures = metrics.totalRequests - metrics.successfulRequests;
const budgetRemaining = allowedFailures - actualFailures;
const budgetPercentUsed = (actualFailures / allowedFailures) * 100;
return {
currentSLI: (currentSLI * 100).toFixed(3) + "%",
allowedFailures,
actualFailures,
budgetRemaining,
budgetPercentUsed: budgetPercentUsed.toFixed(1) + "%",
withinBudget: budgetRemaining >= 0,
};
}Cómo elegir los SLIs correctos
No toda métrica es un buen SLI. Los buenos SLIs se correlacionan directamente con la experiencia del usuario.
# ❌ Infrastructure metrics as SLIs — don't reflect user experience
slis:
- name: "CPU utilization"
target: "below 70%"
- name: "Memory usage"
target: "below 80%"
# CPU can be at 90% while users are perfectly happy
# ✅ User-facing metrics as SLIs
slis:
- name: "Availability"
description: "Proportion of requests that return non-5xx responses"
good_event: "response.status_code < 500"
total_event: "all requests"
target: 99.9%
window: 30d
- name: "Latency"
description: "Proportion of requests served within 500ms"
good_event: "response.duration_ms <= 500"
total_event: "all requests"
target: 95%
window: 30d
- name: "Correctness"
description: "Proportion of responses that pass data validation"
good_event: "response.body passes schema validation"
total_event: "all successful requests"
target: 99.99%
window: 30dCómo implementar el monitoreo de SLOs
Prometheus y Grafana funcionan bien para el seguimiento de SLOs. Define recording rules que precalculen los valores de SLI y generen alertas cuando el burn rate del error budget sea demasiado alto.
# Prometheus recording rules for SLI computation
groups:
- name: sli-recording
interval: 1m
rules:
# Availability SLI - ratio of successful requests
- record: sli:availability:ratio_rate5m
expr: |
sum(rate(http_requests_total{status_code!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# Latency SLI - ratio of fast requests
- record: sli:latency:ratio_rate5m
expr: |
sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))
- name: slo-alerts
rules:
# Alert when error budget burn rate is too high
# Burns through 5% of monthly budget in 1 hour
- alert: SLOBudgetBurnHigh
expr: |
(
1 - sli:availability:ratio_rate5m
) > (14.4 * (1 - 0.999))
for: 5m
labels:
severity: critical
annotations:
summary: "High error budget burn rate - paging on-call"Políticas de error budget
El error budget solo cobra sentido cuando existen consecuencias por agotarlo. Define una política que el equipo acuerde antes de que ocurran incidentes.
## Error Budget Policy
### When budget is healthy (>50% remaining):
- Ship features at normal velocity
- Run chaos engineering experiments
- Perform infrastructure migrations
### When budget is concerning (25-50% remaining):
- Reduce deployment frequency
- Increase testing requirements for changes
- Review recent incidents for patterns
### When budget is critical (<25% remaining):
- Feature freeze — only reliability improvements and critical fixes
- All engineering effort focused on error reduction
- Post-incident reviews required for every budget-consuming event
### When budget is exhausted (0% remaining):
- Complete deployment freeze
- Roll back any recent changes that correlate with budget consumption
- Leadership review of reliability roadmapAlertas de burn rate multiventana
Una alerta de ventana única puede ser demasiado lenta (ventana larga) o demasiado ruidosa (ventana corta). Las alertas multiventana combinan ambos enfoques para lograr una detección rápida con pocos falsos positivos.
# Fast burn: consuming budget 14.4x faster than sustainable
# Detected in 1 hour, confirmed over 5 minutes
- alert: SLOBudgetBurnFast
expr: |
(
(1 - sli:availability:ratio_rate1h) > 14.4 * 0.001
)
and
(
(1 - sli:availability:ratio_rate5m) > 14.4 * 0.001
)
labels:
severity: critical
# Slow burn: consuming budget 3x faster than sustainable
# Detected over 6 hours, confirmed over 30 minutes
- alert: SLOBudgetBurnSlow
expr: |
(
(1 - sli:availability:ratio_rate6h) > 3 * 0.001
)
and
(
(1 - sli:availability:ratio_rate30m) > 3 * 0.001
)
labels:
severity: warningPuntos clave
- Los SLIs miden la calidad percibida por el usuario — elige métricas que se correlacionen con la experiencia real del usuario, no con la salud de la infraestructura
- Los SLOs establecen objetivos de fiabilidad explícitos — "99,9% durante 30 días" es accionable, "ser fiable" no lo es
- Los error budgets equilibran fiabilidad y velocidad — le dan a los equipos permiso para lanzar rápido cuando la fiabilidad está saludable
- Define las políticas del error budget antes de los incidentes — acuerda las consecuencias de agotar el error budget mientras todos están tranquilos
- Usa alertas de burn rate multiventana — detectan tanto incidentes rápidos como degradaciones lentas sin falsos positivos
- Empieza con uno o dos SLIs — disponibilidad y latencia cubren la mayoría de los servicios de cara al usuario; añade más solo cuando sea necesario


