No dedicated repository. SLO / burn-rate language is documented here; platform SLOs and policy inputs are operated in the AI Infra Control Plane.
SLO-Driven Monitoring
Reliability as a fuel gauge: SLIs feed error-budget burn so alerts mean decisions — page, ticket, or freeze — not another ignored red line.
Evidence home
Pattern case — proof lives next door.
How it works
Watch the budget burn — then act.
SLO-Driven Monitoring by Andrey Lesnikov — error budgets turn reliability into spendable fuel with alerts that earn their pages.
-
01
Measure what users feel
Availability and latency SLIs beat host CPU as the story of pain.
-
02
Compute the burn
Multi-window burn rates separate fast fires from slow leaks.
-
03
Alert with intent
Fast burn pages. Slow burn tickets. Noise dies on purpose.
-
04
Act on the budget
Freeze risky change when fuel is gone — reliability policy, not vibes.
Evidence
From problem to proof.
How the system is framed, operated, and proven — not a slide deck summary.
Green dashboards hide user pain: teams lack error budgets, burn-rate alerts, and product-facing reliability language.
You still lack a connected telemetry path from request to workload — fix the observability mesh first.
OpenTelemetry Observability Mesh supplies the river of spans. Self-Healing and Incident Runbooks act when budgets burn.
Service ownership, error budgets, burn-rate alerts, noisy dependencies, and product-facing reliability language.
Related
Nearby systems.
OpenTelemetry Observability Mesh
Metrics, logs, and traces often exist separately, making incidents slower and ownership unclear
Request path explainable end-to-end
Self-Healing Infrastructure
Transient infrastructure failures can become user-facing incidents when recovery depends on manual detection
Common failures recover with guardrails
Incident Runbook Automation
Incidents are slower when context, dashboards, logs, and recovery steps live in different places
Repeatable response → lower MTTR