How many SLOs per service is reasonable?

Start with 1–2 SLOs per critical user journey, usually 3–5 per product. More than that and you’ll spend your life in meetings. Keep the long tail of metrics on dashboards, not pagers.

What if we don’t have Prometheus/Argo/Istio?

Great. Use what you have: Datadog monitors for burn rate, LaunchDarkly or OpenFeature for flag gates, AWS ALB/NLB metrics for success/latency, Spinnaker for automated rollouts. The pattern matters more than the tools.

How do we pick the right objective (99.9 vs 99.95)?

Back into it from user tolerance and incident review. If a 10‑minute checkout outage a month is acceptable, 99.98% is your ceiling. Then stress‑test with historical data to ensure you can operate within budget most months.

Won’t gating rollouts slow us down?

Only if your quality is already poor. Healthy teams pass gates quickly. And when things do go wrong, automatic rollback is much faster than a human hunt.

What about internal platforms and batch jobs?

Use SLIs that match the job: queue latency, backlog depth, and SLA completion window success. Page on predicted misses (backlog growing + steady input), not on CPU spikes.

Reliability-observability · Nov 6, 2025 · 10 minute read

The SLIs That Actually Change On‑Call: Predict Failures, Gate Rollouts, Ship Calmly

Stop paging on CPU and start shipping based on error budgets that predict pain before customers feel it.

Back to all posts

The SLIs That Actually Change On‑Call: Predict Failures, Gate Rollouts, Ship Calmly

Key takeaways

Implementation checklist