Compare
BurnRateSurgeon vs Grafana SLO
Grafana SLO creates the objective, the recording rules and the burn-rate alert together, and evaluates continuously from there. BurnRateSurgeon replays a proposed change against the past before it merges.
The honest difference
Grafana SLO provisions an SLO with its recording rules and burn-rate alert conditions in one step inside Grafana Cloud, and charts the SLI continuously once the objective exists. What it does not do is re-evaluate the alert path itself over history — a dashboard shows what burned, not which rule stayed silent while it did. BurnRateSurgeon replays the proposed rule change against real historical time-series before it ships, and classifies exactly where the alert would have missed or stormed.
Grafana SLO, capability by capability
Every row below is scored the same way it is on the full five-product table on the landing page — the same marks, the same notes, checked against Grafana SLO’s own documentation in September 2026.
| Capability | BurnRateSurgeonAlert forensics | Grafana SLOSLO in Grafana Cloud |
|---|---|---|
| Turns an SLO spec into alert rulesMulti-window multi-burn-rate rules and their recording groups, generated for you. | PartialPrescribes a fix as a rule diff. It does not author your SLO spec — bring Sloth or Pyrra for that. | YesCreates the SLO with its recording rules and burn-rate alerts in one step. |
| Replays your own history against the proposed rulesEvaluates the rules you are about to ship over real past time-series, respecting scrape lag, evaluation intervals, for-clauses and inhibit chains. | YesThe product. A deterministic replay over a TSDB snapshot, down to the scheduler. | PartialCharts the SLI once the SLO exists. The alert path itself is not re-evaluated over the past. |
| Says why an alert missed or stormedAttributes a root cause to each failure — window-boundary gap, evaluation lag, inhibit loop, cardinality explosion — and shows the evidence behind it. | YesEvery finding is classified and carries the incidents it was attributed from. | NoDashboards show what burned, not which rule was silent while it burned. |
| Fails a pull request on an alerting regressionBlocks the merge when a rule change turns an incident the old rules caught into one the new rules would miss. | YesThe PR gate replays the branch and comments the incidents the change would have lost. | PartialSLOs are provisionable as code. There is no replay result to gate the merge on. |
| Cross-vendor corpus of alerting failure signaturesA catalogue of failure modes observed in real production alerting, indexed across vendors and readable by your own agents over MCP. | YesPrometheus, Grafana, Mimir, VictoriaMetrics and Datadog signatures, in one index. | NoNo shared record of failure modes across the estates it runs on. |
| Runs offline, on data that stays in your networkWhether the analysis can happen without shipping your time-series to a vendor. | YesThe CLI reads a local snapshot. Nothing leaves the cluster unless you upload it. | PartialGrafana Cloud hosts it; self-managed needs Enterprise. The OSS build has no SLO feature. |
| Open-source coreHow much of the thing you are evaluating you can read, fork and run for free. | YesCLI and replay engine are Apache-2.0. The corpus and shadow-mode are the paid part. | PartialGrafana itself is AGPL-3.0. The SLO feature is not part of that distribution. |
Comparing more than one alternative? See all five side by side, or open an issue if something here reads as out of date or unfair.
When to choose which
Choose Grafana SLO when
- You are already standardised on Grafana Cloud and want the SLO, its recording rules and its burn-rate alerts provisioned together in one place.
- You need continuous, at-scale SLO evaluation across hundreds of services with native Grafana dashboards.
- You are on Grafana’s AGPL-3.0 core and do not need the hosted SLO feature specifically.
Choose BurnRateSurgeon when
- You want to know, before a rule change ships, which past incidents it would have missed or stormed.
- You need a pull-request gate — a bot comment on the diff that changed the rule — not only a dashboard that renders after it merges.
- You want the same forensic report whether the source is Grafana Cloud, Prometheus, Mimir, VictoriaMetrics or Datadog.
Grafana SLO and BurnRateSurgeon, in practice
- Does Grafana SLO replay history the way BurnRateSurgeon does?
- No. It charts the SLI once the SLO exists and evaluates continuously going forward. The alert path itself is not re-evaluated over the past, which is the gap BurnRateSurgeon’s replay engine fills.
- Is Grafana SLO open source?
- Grafana itself is AGPL-3.0, but the SLO feature is a Grafana Cloud capability and is not part of the open-source distribution. BurnRateSurgeon’s CLI and replay engine are Apache-2.0 and run entirely offline.
- Can I self-host Grafana SLO?
- Only with a Grafana Enterprise licence — the OSS build has no SLO feature. BurnRateSurgeon’s open-source CLI needs no licence at all; the paid tier adds shadow-mode, the PR gate and the private corpus.
- Do the two compete for the same job?
- Mostly not. Grafana SLO declares and renders the objective continuously; BurnRateSurgeon replays the alert rules defending it against real history before and after they ship. Most teams that report SLOs in Grafana also run both.
Comparing something else?
Stop debugging alerts after the incident
Validate your burn-rate rules against real history. The open-source CLI is free forever — the SaaS adds shadow-mode, PR gates, and a cross-vendor failure-signature corpus.
Not ready yet? Read one failure a week instead.