Pyrra

Pyrra turns a short SLO declaration into the Prometheus recording rules and alerts that track an error budget. Hand-written multi-window burn-rate alerts are long, repetitive PromQL that is easy to get wrong; Pyrra generates them from a target, a window and an indicator, and adds a UI that lists every SLO sorted by remaining budget.

What it is

A single Go binary with a React UI, maintained by Matthias Loibl and Nadine Vehling in their free time, under the Apache 2.0 licence. The current release line is v0.10.x: v0.10.0 shipped on 30 April 2026, and v0.10.2 (18 September 2026) is the latest patch. The official Helm chart (pyrra-dev/helm-charts, chart 1.14.0) pins app version v0.10.2. The CRD API is still pyrra.dev/v1alpha1.

v0.10.0 is the release to know about:

• Performance mode (performanceOverAccuracy: true) replaces full-window increase() rules with 5-minute increases summed by a subquery.
• Alert severity overrides per burn-rate tier in the SLO spec.
• Prometheus 3 histogram support. The le label normalization differs between Prometheus 2 and 3; migration mode, now on by default, makes rules work with both.
• pyrra_url annotations on every generated alert, linking to the SLO page when an external URL is set.
• A new UI on shadcn/ui and Tailwind.

The two patches since are fixes: v0.10.1 corrected latency SLOs that double-counted the denominator, and v0.10.2 scoped performance-mode long-rule subqueries to their own SLO.

Pyrra belongs to the Prometheus family of tools. It reads from Prometheus (or Thanos, or Mimir) and writes Prometheus rules. It does not store metrics itself.

How it works

The binary runs in one of three roles:

• api serves the UI and queries Prometheus for the graphs.
• kubernetes is an operator. It watches ServiceLevelObjective objects and writes one PrometheusRule per SLO for the Prometheus Operator to load (or a ConfigMap with --config-map-mode).
• filesystem reads SLO YAML from disk and writes rule files, then POSTs to Prometheus /-/reload.

A fourth command, generate, converts SLO files to rules once, for CI pipelines.

Each SLO's labels are copied onto the generated PrometheusRule. That copy is how a Prometheus ruleSelector picks it up. The rules record an increase over the full window plus one burn-rate series per alert window, named after the source metric (for example http_requests:burnrate5m). The alerting rules then compare burn rates with the target.

The four alerts use the multi-window, multi-burn-rate method. Each alert pairs a long window with a short one, so the alert needs a sustained burn to fire and clears soon after the burn stops. The windows scale with the SLO window. For a 28-day SLO they are:

Tier	Long / short window	Burn factor	for	Default severity
Fast	1h / 5m	14	2m	critical
Medium	6h / 30m	7	15m	critical
Slow	1d / 2h	2	1h	warning
Long-term	4d / 6h	1	3h	warning

A fifth alert, SLOMetricAbsent (critical by default), fires when the source metric disappears. Without it, an SLO that loses its data reads as 100% available.

When to use it

Reach for it when:

• Prometheus and the Prometheus Operator already run, and SLOs should live in Git next to the services.
• Several services need the same SLO shape (availability ratio, latency threshold, probe success) and nobody wants to maintain burn-rate PromQL by hand.
• A page sorted by remaining budget is wanted, so the worst SLO shows first.
• Long windows over high-cardinality metrics make rule evaluation slow, and performance mode can fix it.

Skip it when:

• There is no Prometheus-compatible backend. Pyrra generates PromQL and nothing else.
• SLOs are composite (weighted across services, or multi-step user journeys). The FAQ says complex SLOs are out of scope; write those rules by hand.
• A hosted observability product already provides SLOs with budget policies and reporting.

At a glance

Core concepts

• ServiceLevelObjective — the one object: target (a string such as "99.5", because CRDs do not support floats), window (such as 28d) and indicator.
• Indicators — ratio (errors / total), latency (bucket at a threshold / count), latencyNative (native histograms with a latency: 200ms threshold) and bool_gauge (a 0/1 gauge such as probe_success).
• Grouping — labels that split one SLO into one budget per value (per route, per target).
• pyrra.dev/ labels — labels with this prefix are passed to the generated series without the prefix (for example pyrra.dev/team becomes team).
• Generic rules — --generic-rules also records same-named series for every SLO, which the bundled Grafana dashboards need.

Key facts

Item	Value
Licence	Apache 2.0
Current release	v0.10.2 (Sept 2026); chart 1.14.0
CRD	servicelevelobjectives.pyrra.dev, v1alpha1
Backends	Prometheus, Thanos (partial responses off, downsampling), Mimir ruler
Output	PrometheusRule, ConfigMap, or rule files on disk
UI port	9099 (chart service); operator metrics on 8080
Scale-out	One instance per Prometheus (pair); leader election for replicas
Scoping	--namespaces limits the operator to listed namespaces

Pyrra and Sloth

Aspect	Pyrra	Sloth
Input	ServiceLevelObjective CRD or YAML	PrometheusServiceLevel CRD or YAML
Runs as	Operator + API/UI, or file mode	Operator or CLI generator
UI	Built in, sorted by budget	Grafana dashboard
Alerts	Four burn-rate tiers + absent	Page and ticket alerts
Plugins	Fixed indicator types	SLI plugins for custom PromQL

How to integrate

Install from the official chart and point the API at the Prometheus that evaluates the rules:

helm repo add pyrra https://pyrra-dev.github.io/helm-charts
helm install pyrra pyrra/pyrra -n monitoring -f values.yaml

# values.yaml
prometheusUrl: http://prometheus-operated.monitoring.svc.cluster.local:9090
externalUrl: https://pyrra.example.com   # adds pyrra_url to every alert
genericRules:
  enabled: true        # needed for the Grafana dashboards
dashboards:
  enabled: false
serviceMonitor:
  enabled: true
validatingWebhookConfiguration:
  enabled: false       # true requires cert-manager

An availability SLO from a Blackbox probe, with the label kube-prometheus-stack's default ruleSelector matches:

apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: site-probe-availability
  namespace: monitoring
  labels:
    release: kube-prometheus-stack   # must match the Prometheus ruleSelector
spec:
  target: "99.5"
  window: 28d
  description: Public site answers HTTPS probes from outside the app.
  indicator:
    bool_gauge:
      metric: probe_success{job="blackbox-https"}
      grouping: [instance]

A request-ratio SLO with a severity override and performance mode:

spec:
  target: "99"
  window: 28d
  indicator:
    ratio:
      errors:
        metric: http_requests_total{job="api",code=~"5.."}
      total:
        metric: http_requests_total{job="api"}
  alerting:
    severities:
      slowBurn: info
  performanceOverAccuracy: true

Check the result with kubectl get prometheusrules -n monitoring and look for the SLO's recording rules on the Prometheus Rules page.

In the GL stack

Pyrra v0.10.2 runs on the management cluster, next to the Prometheus hub, Alertmanager and Grafana. The beta and prod clusters run Prometheus in agent mode and remote-write to that hub, so every SLO is evaluated in one place.

• SLOs as objects. Each SLO is a ServiceLevelObjective CRD. Pyrra turns it into Prometheus recording rules and multi-window burn-rate alerts, and the hub's Alertmanager sends those alerts by email on the same routes as the other alerts.
• Availability from the outside. The Blackbox Exporter, also on the management cluster, probes the public product sites and APIs over HTTPS from outside the apps. Its results feed the availability SLOs, so an SLO measures what a visitor sees, not what a pod reports about itself.

Gotchas

• Rule selector labels. kube-prometheus-stack's default ruleSelector only matches PrometheusRule objects that carry the Helm release label. Pyrra copies the SLO's labels onto the rule, so an SLO without that label produces a rule that Prometheus never loads, and no error is shown.
• Target is a string. target: 99.5 without quotes fails CRD validation. Write "99.5".
• The bool gauge key is snake case. The field is bool_gauge, not boolGauge, even though the docs list the type as boolGauge.
• Long windows are expensive. increase(metric[28d]) scans four weeks of samples on every evaluation. Performance mode fixes this but adds a small inaccuracy (typically under 1%). The docs advise care above a 99% target, where the error budget itself is under 1%.
• Upgrade to v0.10.1 or later for latency SLOs. Before v0.10.1, latency SLOs double-counted the denominator. Before v0.10.2, performance-mode long rules could pick up another SLO's series.
• Absent alerts fire on day one. An indicator that selects no series triggers SLOMetricAbsent. Check the selector in Prometheus before applying the SLO, or set alerting.absent: false while staging.
• Grafana dashboards need generic rules. The bundled dashboards query generic series names that exist only with --generic-rules.
• Webhook needs cert-manager. The validating webhook is off by default; turning it on without cert-manager leaves the API server unable to reach it, and with failurePolicy: Fail SLO applies are rejected.

Risks

• Project health. Two maintainers who work on it in their spare time. Releases are steady: one minor line and two patches in 2026. The API is still v1alpha1, so field changes stay possible.
• Lock-in. Low. Pyrra's output is plain Prometheus rules; removing it leaves those rules readable and portable, and the SLO YAML is short to port to Sloth or OpenSLO.
• Security. The api command has no sign-in options of its own, so put the UI behind a proxy or SSO gate. The operator needs write access to PrometheusRule objects, so scope it with --namespaces where possible.
• Correctness. Generated alerts are only as good as the indicator. A wrong selector produces confident, wrong budgets.

Alternatives

• Sloth — pick it for an SLO generator with SLI plugins and OpenSLO input, and when the Grafana dashboards are enough UI.
• Hand-written rules (slo-libsonnet or plain PromQL) — pick it for a few SLOs that need composite or custom logic.
• Grafana SLO (Grafana Cloud) — pick it when the stack is already on Grafana Cloud and a managed SLO product is acceptable.
• OpenSLO with a generator — pick it when SLO definitions must stay vendor-neutral across more than one backend.

Related

• Prometheus and Alertmanager — the hub that evaluates the generated rules and the router that sends the alerts.
• Blackbox exporter — the outside-in probes behind the availability SLOs.
• Grafana — dashboards over the same Prometheus series.
• Observability layer — how Pyrra fits with the rest of the monitoring services.
• Official: pyrra-dev/pyrra on GitHub, Releases, Performance mode, Helm chart.