How do I pick my first SLO targets?

Start with what you can meet based on historical data. If your checkout availability has been 99.7–99.85% over the last quarter, set 99.8% or 99.85%, not 99.99%. Use a 28-day window and revisit quarterly. The point is to create a useful error budget signal, not win an uptime beauty contest.

Do I need Istio to implement SLIs/SLOs?

No, but a mesh makes it easier. You can use NGINX Ingress, Envoy, or app-level metrics (OpenTelemetry) to expose request counts and latency histograms. What matters is consistent metrics for total vs error counts and latency buckets.

What about composite services and partial failures?

Model user journeys at the edge if possible (e.g., via API gateway metrics) and add service-level SLOs where necessary. If the page is triggered from the edge SLO, use service SLOs to triage. Avoid clever weighted composites until you’ve mastered basics.

Won’t slow-burn alerts cause alert fatigue?

Use multi-window thresholds and route slow burns to tickets unless they continue to burn. We page on fast burns; we ticket on slow burns. Most teams see fewer, earlier, and more actionable signals with this pattern.

Case-studies · Nov 28, 2025 · 9 minute read

From Pager Hell to Predictable On-Call: How SLOs Cut Pages 65% in 90 Days

We stopped chasing CPU graphs and started defending error budgets. The result: fewer pages, faster MTTR, calmer engineers, safer releases.

Back to all posts

From Pager Hell to Predictable On-Call: How SLOs Cut Pages 65% in 90 Days

Key takeaways

Implementation checklist