SLO vs SLA vs SLI — which do I alert on?

Alert on SLO burn (via SLIs). SLAs are contracts with customers—don’t page your team on legal terms. SLIs are the raw signals; SLOs set expectations; error budgets determine when to page.

We don’t use Prometheus. Can we still do this?

Yes. The pattern works with Datadog, New Relic, or Cloud Monitoring. Use their query languages to implement burn-rate alerts. We used Prometheus/Sloth here because it was already in place and easy to automate via GitOps.

How many SLOs per service?

Start with 2–3 per user journey (availability + latency). Too many SLOs become noise; too few miss real failures. Expand only when a journey proves important to the business.

Do SLOs slow down delivery?

They speed it up. By gating risky changes and reducing alert noise, teams shipped 38% more frequently in this case. Error budgets clarify when to push and when to pause.

What about AI features with probabilistic outputs?

Treat correctness as an SLI. Track rejection rates, groundedness checks, or human override rates. The same burn-rate principles apply—define what ‘good enough’ is and alert when you’re burning too fast.

Case-studies · Oct 16, 2025 · 9 minute read

The SLO Rollout That Stopped the Pager Storm: Cutting MTTR 77% in 90 Days

Turning noisy alerts into decisive action with Prometheus, Sloth, and error budgets.

Alex Mercer

Principal Engineer, GitPlumbers

20 years fixing broken systems from bare metal to Kubernetes. Former SRE lead at a unicorn you’ve definitely second-guessed in production. Allergic to silver bullets; fond of boring, automated reliability.

We didn’t fix incidents by adding more dashboards. We fixed them by agreeing on what ‘good’ is and letting error budgets drive the pager.

Back to all posts

The SLO Rollout That Stopped the Pager Storm: Cutting MTTR 77% in 90 Days

Key takeaways

Implementation checklist