Replay & determinism

What gets replayed

A replay loads a TSDB snapshot, a rules file — Prometheus recording and alerting rules, optionally an Alertmanager config, or a single Datadog export bundle — and evaluates the alerting rules over the recorded window exactly as the vendor would have, including for: clauses (an alert does not fire until N consecutive evaluation periods hold true) and recording-rule cascades, evaluated in topological order so a rule that reads another recording rule's output sees it computed first.

Determinism

The same input always produces a byte-identical report. Every replay is fingerprinted by an input_checksum over its snapshot, rules and Alertmanager config — submitting the same one twice returns the cached run instead of re-computing it (POST /orgs/:orgId/replays answers 200 with the existing run rather than 202), and the CLI, the SaaS API and the PR-gate Action all share this guarantee because they share the same replay engine package.

The report

A finished replay's report names every alert that would have fired, when, and — for every one the classifier has an opinion on — which of the six canonical failure classes it maps to:

{
  "alertname": "CheckoutErrorBudgetBurn",
  "rootCause": "window_boundary_miss",
  "method": "hybrid",
  "confidence": 0.91,
  "missedCount": 1,
  "prescribedFix": {
    "diff": "- for: 10m\n+ for: 2m",
    "explanation": "Add a fast-burn arm on a short window."
  }
}

method is rule_based when the deterministic detectors alone reach the trust threshold, workers_ai when only the corpus's nearest signature does, and hybrid when both agree — never a black box guess with no rule or signature behind it.

Where to go next

• Guides — what each of the six classes is, how the classifier detects it, and how to fix it.
• Integrations — which vendors brs replay executes directly.
• API reference — the endpoints that submit a rule set and read back a classified report.