Implement SLOs and Error Budgets

SLO Implementation Guide designs comprehensive Service Level Objective frameworks, establishes meaningful SLIs, and builds monitoring systems that balance reliability with feature velocity, centered on error-budget-based engineering practice.

Its foundation step, an SLOFramework design, analyzes service context (service tier, user expectations, business impact, technical constraints, dependencies) and recommends one of four service tiers with concrete numeric targets: critical (99.95% availability, 100ms p99 latency, 0.001 error rate - examples: payment processing, authentication), essential (99.9% availability, 500ms p99, 0.01 error rate - search, product catalog), standard (99.5% availability, 1000ms p99, 0.05 error rate - recommendations, analytics), and best-effort (99.0% availability, 2000ms p99, 0.1 error rate - batch processing, reporting). It also maps critical user journeys into step-by-step SLI candidates, illustrated with a login journey whose steps carry explicit thresholds: load the login page in under 2 seconds (availability), submit credentials in under 500ms (latency), validate authentication with under 0.1% failures (error rate), and load the dashboard in under 3 seconds (latency).

SLI selection and measurement covers availability, latency, error rate, throughput and quality SLI types, chosen by service type (API, web, batch, streaming). For API services it gives Prometheus query patterns: availability as the ratio of non-5xx request rate to total request rate (with an exclusion variant that drops /health and /metrics endpoints), latency as the fraction of requests under a percentile threshold using http_request_duration_seconds_bucket, and error rate broken into client errors (4xx), server errors (5xx), timeout errors (504) and business-logic errors, alongside an overall success-rate query that counts only 5xx as failures, with 4xx excluded from the error count.

Error budget calculation is implemented as an ErrorBudgetManager: total budget in minutes is window_days * 24 * 60 * (1 - slo_target/100); current status compares actual versus expected uptime over a date range to compute consumed minutes, remaining budget, and a burn rate; and days until exhaustion is projected as window_days * (1 - burn_rate) / burn_rate when the burn rate is positive. Status is classified as exhausted when remaining budget hits zero, critical above a 2x burn rate, warning above 1.5x, and attention above 1x.

SLO monitoring uses Prometheus recording rules for request rate, multi-window success rate (5m/30m/1h), latency percentiles (p50/p95/p99) and error-budget burn rate, paired with multi-window multi-burn-rate alerts: a fast-burn alert fires when the 5m and 1h burn rates both exceed 14.4x (consuming 2% of the monthly budget in 1 hour), and a slow-burn alert fires when the 30m and 6h burn rates both exceed 3x (10% of the budget in 6 hours). A Grafana dashboard generator builds panels for a 30-day SLO summary stat (red/yellow/green thresholds at 99.5%/99.9%), an error-budget-status gauge showing remaining budget (red/yellow/green thresholds at 20%/50%), and a burn-rate-trend graph plotting the 1h/6h/24h burn rates. An SLO template library provides ready-made specs for common service types - an API service template (99.9% availability over 30 days, 95% of requests faster than 500ms) and a data-pipeline template (99% of batches processed within 30 minutes over 7 days, 99.95% record completeness). SLO automation can auto-generate SLOs for discovered services by analyzing service characteristics and selecting a matching template. The skill also covers a weekly SLO review meeting format - a 30-minute agenda split into SLO performance review, incident review and decision-making - plus SLO reporting and SLO-based decision-making guidance for weighing reliability work against feature velocity.

Use it for defining SLIs/SLOs and error budgets for services, building SLO dashboards, alerts or reporting workflows, aligning reliability targets with business priorities, or standardizing reliability practices across teams. Do not use it when you only need basic monitoring without reliability targets, when there is no access to service telemetry or metrics, or for a task unrelated to service reliability. Its safety notes: avoid setting SLOs without stakeholder alignment and data validation, and do not alert on metrics that include sensitive or personal data.

Input is $ARGUMENTS describing the service and its reliability requirements, plus access to its telemetry. Output is an SLO specification (service tier, SLI definitions, SLO targets, error-budget policy and a measurement strategy), the SLI query implementations for the chosen service type, and an error-budget status report with consumed/remaining minutes, burn rate and a projected exhaustion date.

It suits SRE and platform teams defining reliability targets for a service, building error-budget-based alerting and dashboards, and needing a concrete service-tier framework to align reliability investment with business impact.