Sloth is an Apache-2.0 licensed, Go-based generator that turns a short service level objective specification into complete Prometheus SLO recording rules, metadata rules, and multi window multi burn alert rules, and it is aimed at platform, SRE, and on-call teams that already run Prometheus and want uniform SLOs across many services and teams.

What it is

Sloth lives in the Prometheus monitoring ecosystem and replaces the hand-written bundle of recording rules, alerting rules, and dashboard panels that teams normally assemble by hand for each service they measure. Instead of repeating PromQL for SLI ratios, burn-rate windows, and page and ticket alerts per service, an operator writes one SLO spec and lets Sloth expand it into the concrete Prometheus artifacts. The tool is built on the Google SLO implementation and the multi window multi burn alerting framework, and it exposes those ideas through a YAML format whose version field reads prometheus/v1.

The concrete problem is uniformity and reliability across teams. Sloth gives every service the same rule shape, the same safe SLO period windows of 30 and 28 days by default, and the same alert semantics, while still letting each SLO carry labels such as owner, repo, and tier, and its own category labels. The spec also supports OpenSLO (v1alpha), so those definitions are not confined to Sloth alone. Sloth is actively maintained and in continuous development, with current work on internal improvements to make generation more extensible and adaptable to real-world use cases.

Key capabilities

• sloth generate -i ./examples/getting-started.yml reads one SLO spec and emits all required Prometheus rules.
• Autogenerates Prometheus SLI recording rules in different time windows, plus SLO metadata rules.
• Autogenerates multi window multi burn alert rules with separate page and ticket alert tiers.
• SLO spec validation, including a validate command intended for GitOps and CI pipelines.
• Kubernetes controller/operator mode with CRDs, alongside Prometheus-operator support.
• Support for different SLI types and SLI plugins, including a library of common SLI plugins.
• OpenSLO v1alpha support, automatic Grafana SLO dashboard, and a single binary CLI.

Who uses it and how

• SRE and observability teams running Prometheus across many services, who want one uniform way of creating SLOs instead of per-team rule authorship.
• Platform teams on Kubernetes that deploy Sloth in operator mode with CRDs, declaring SLOs as cluster objects next to their Prometheus-operator setup.
• GitOps teams that validate SLO specs in CI before merge, so bad specs never reach the cluster.
• On-call owners who route page and ticket alerts through labels such as severity, routing_key, and slack_channel on the generated alerts.
• Teams that prefer specs written once against the OpenSLO schema rather than a bespoke in-house format.

Getting started

Install the single binary CLI and run sloth generate -i ./examples/getting-started.yml against a prometheus/v1 spec to produce the generated Prometheus rules. Documentation, examples, and additional usage details live at https://sloth.dev.

How it compares

Sloth implements the Google SLO approach and the multi window multi burn framework rather than inventing its own alerting math, so teams already familiar with those two references will recognize the outputs. Where the surrounding ecosystem offers the OpenSLO specification as a portable SLO format, Sloth consumes it at v1alpha, which means Sloth sits as a generator between a shared SLO definition and a Prometheus rule set rather than as a separate observability backend.

When to use it — and when not to

Pick Sloth when Prometheus is the metrics system of record and the goal is consistent SLO rules and alerts across many services, since outside Prometheus the generated recording and alerting rules have little to act on. Operator mode assumes a Kubernetes cluster with CRDs, and the automatic SLO dashboard assumes Grafana is already deployed, so a self-hoster must operate those pieces too. Teams that need fully bespoke alert math per service may find the generated multi window multi burn structure a constraint, even with label customization and the ability to disable specific alert types.

sloth generate -i ./examples/getting-started.yml

version: "prometheus/v1"
service: "myservice"
labels:
  owner: "myteam"
  repo: "myorg/myservice"
  tier: "2"
slos:
  # We allow failing (5xx and 429) 1 request every 1000 requests (99.9%).
  - name: "requests-availability"
    objective: 99.9
    description: "Common SLO based on availability for HTTP request responses."
    labels:
      category: availability
    sli:
      events:
        error_query: sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[{{.window}}]))
        total_query: sum(rate(http_request_duration_seconds_count{job="myservice"}[{{.window}}]))
    alerting:
      name: "MyServiceHighErrorRate"
      labels:
        category: "availability"
      annotations:
        # Overwrite default Sloth SLO alert summmary on ticket and page alerts.
        summary: "High error rate on 'myservice' requests responses"
      page_alert:
        labels:
          severity: "pageteam"
          routing_key: "myteam"
      ticket_alert:
        labels:
          severity: "slack"
          slack_channel: "#alerts-myteam"