// the find
pyrra-dev/pyrra
Making SLOs with Prometheus manageable, accessible, and easy to use for everyone!
Pyrra is a Kubernetes operator and UI that translates SLO definitions into Prometheus recording rules and multi-burn-rate alerts. You define an SLO in YAML, Pyrra generates the PromQL recording rules and wires up the alerting math. It targets teams running Prometheus (or Thanos/Mimir) who want SLOs without hand-rolling the burn rate calculations.
The core value — auto-generating the correct burn rate recording rules from a simple YAML spec — saves hours of PromQL work and sidesteps a common class of alerting bugs where teams get the math slightly wrong. Thanos and Mimir support are first-class, not afterthoughts: downsampling headers and tenant IDs are handled in the query layer. The single-binary architecture (api, kubernetes, filesystem modes) keeps operational overhead low. The protobuf/connect-go API means the UI isn't just a cosmetic layer — it's calling a typed API, which makes it easier to build alternative frontends or tooling on top.
Maintained 'mostly in free time' by two people, and it shows in the pace: v0.7 has been the latest for a while with no clear roadmap toward v1. The SLO model only covers ratio (error rate) and latency indicators — more complex SLOs like apdex or custom compound metrics aren't supported and you're on your own. No multi-cluster support: you need one Pyrra instance per Prometheus pair, which becomes annoying at even moderate scale. The UI is functional but thin — you can view SLO state but there's no guided flow for creating or editing SLOs without hand-editing YAML.