Skip to content

Sloth: SLOs and error budget burn

SRE · SLO
Not studied

Added 2026-10-29.

Problem

The "site is down" alert fires on every one-minute dip, while slow degradation over a week goes unnoticed. There is no agreement on how many errors are acceptable.

Solution

Sloth is "the easiest way to generate SLOs for Prometheus": it "generates understandable, uniform and reliable Prometheus SLOs for any kind of service", using "a simple SLO spec that results in multiple metrics and multi window multi burn alerts". Define the SLO in a short spec and generate Prometheus recording and alerting rules from it. A follow-up to Four Golden Signals and Recording rules.

Example

SLI from the Blackbox Exporter: the share of failed probes. The raw.error_ratio_query format follows the repository's examples/raw-home-wifi.yml.

version: "prometheus/v1"
service: "devops-kb"
slos:
  - name: "site-availability"
    objective: 99.5
    description: "The site responds to external HTTP probes."
    sli:
      raw:
        error_ratio_query: |
          1 - avg_over_time(probe_success{instance="https://devops-kb.is-a.dev/"}[{{.window}}])
    alerting:
      name: DevopsKbAvailability
      page_alert:
        labels:
          severity: critical
      ticket_alert:
        labels:
          severity: warning

sloth generate -i slo.yaml -o slo-rules.yaml
promtool check rules slo-rules.yaml

When to use

When the service has a clear SLI and someone to respond to the alert. The generator doesn't decide what counts as an error.

Source

How to apply it yourself

  1. Pick one service and an SLO target.
  2. Generate the rules, check them with promtool check rules, load them into Prometheus.
  3. Make sure the recording rules are evaluated and the alert reaches its recipient.
  4. Mark it "Studied" after the first month with an error budget report.