Is BurnRateSurgeon a replacement for Sloth?

No. Sloth turns an SLO spec into Prometheus rules; BurnRateSurgeon takes rules — Sloth’s or hand-written — and replays them against your own history. Most teams that run BurnRateSurgeon also run Sloth or Pyrra to generate the rules in the first place.

Can I use Sloth and BurnRateSurgeon together?

Yes, and that is the common path. Generate the rule group with Sloth, then point the BurnRateSurgeon CLI at the same rules.yml and a TSDB snapshot to see where it would have missed or stormed.

Does sloth validate check the rules against real incidents?

sloth validate checks that the generated YAML is well-formed. It does not evaluate the rules over time-series data, so it cannot say whether a rule would have caught a specific incident — that evaluation is what the replay engine does.

Is Sloth open source?

Yes, Apache-2.0, end to end. So is the BurnRateSurgeon CLI and replay engine — only shadow-mode, the PR gate and the private corpus are part of the paid subscription.

Compare

BurnRateSurgeon vs Sloth

Different jobs on the same rules. Sloth writes the multi-window multi-burn-rate rules your SLO needs; BurnRateSurgeon replays them against real history to say where they would have broken.

Sloth’s own documentation

The honest difference

Sloth is the reference implementation for turning an OpenSLO spec into Prometheus recording rules and burn-rate alerts — a generator, and a good one. It validates the YAML it just wrote, but it never runs that YAML over a time-series: whether the rule would actually have caught last month’s incident is a question Sloth was not built to answer. BurnRateSurgeon starts where Sloth stops — it takes the rules, Sloth’s or hand-written, and deterministically replays them against a TSDB snapshot, classifying every miss and every storm by root cause.

Sloth, 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 Sloth’s own documentation in September 2026.

BurnRateSurgeon compared with Sloth, by capability
Capability	BurnRateSurgeonAlert forensics	SlothSLO generator
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.	YesIts core job, and the reference implementation for Prometheus and OpenSLO.
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.	NoValidates the spec and the YAML it wrote; it never evaluates either over data.
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.	NoOut of scope by design: it is a generator, not an evaluator.
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.	Partialsloth validate runs in CI and catches an invalid spec — a schema check, not a behavioural one.
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.	NoNone — and none is expected of a single-binary generator.
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.	YesA single binary over local YAML — nothing to send anywhere.
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.	YesApache-2.0, end to end. Nothing is held back behind a paid tier.

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.

Choose Sloth when

You need Prometheus burn-rate rules and their recording-rule groups generated from an SLO spec, and nothing past that.
You want a single Apache-2.0 binary with no infrastructure of its own to run or operate.
OpenSLO compatibility across tooling matters more than evaluating the rules it produced.

Choose BurnRateSurgeon when

You already trust the rules Sloth generated and want to know whether they would have caught the last six months of incidents.
You need a pull-request gate that replays a rule change against real history, not one that only validates the YAML.
You want a cross-vendor failure-signature corpus behind the classification, not just a generator with no memory of past failures.

Sloth and BurnRateSurgeon, in practice

Is BurnRateSurgeon a replacement for Sloth?: No. Sloth turns an SLO spec into Prometheus rules; BurnRateSurgeon takes rules — Sloth’s or hand-written — and replays them against your own history. Most teams that run BurnRateSurgeon also run Sloth or Pyrra to generate the rules in the first place.
Can I use Sloth and BurnRateSurgeon together?: Yes, and that is the common path. Generate the rule group with Sloth, then point the BurnRateSurgeon CLI at the same rules.yml and a TSDB snapshot to see where it would have missed or stormed.
Does sloth validate check the rules against real incidents?: sloth validate checks that the generated YAML is well-formed. It does not evaluate the rules over time-series data, so it cannot say whether a rule would have caught a specific incident — that evaluation is what the replay engine does.
Is Sloth open source?: Yes, Apache-2.0, end to end. So is the BurnRateSurgeon CLI and replay engine — only shadow-mode, the PR gate and the private corpus are part of the paid subscription.

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.