Service Level Objectives (SLOs)

Best Practice: Service Level Objectives (SLOs)

A Service Level Objective (SLO) is a target value for a Service Level Indicator (SLI) over a time window, such as "99.9% of HTTP requests succeed over 28 days." An SLI is the measured ratio of good events to total events. SLOs make reliability a quantified, agreed-upon target rather than an implicit assumption. They matter because they let teams decide objectively when to invest in reliability versus shipping features, and they anchor the error-budget model that protects users while preserving velocity.

During migrations, SLOs give you a concrete contract for "how reliable is reliable enough," so you can prove the new system is at least as good as the old one before cutover. They also align engineering and product on a single number, which prevents the common standoff where one side wants more features and the other wants more stability. An SLO is not a Service Level Agreement (SLA): the SLA is a contractual promise to customers, usually looser than the internal SLO, with penalties attached. Setting the SLO tighter than the SLA gives you a buffer to detect and fix problems before they breach a customer commitment.

A good SLO is specific, measurable, and tied to a clear user outcome. It should be achievable with reasonable effort and meaningful enough that missing it actually matters. Aiming for more nines than users can perceive wastes engineering effort and slows delivery for no real benefit.

Step-by-Step Implementation Guidance

1. Identify critical user journeys (login, checkout, search) rather than every endpoint.
2. For each journey, choose 1-3 SLIs that reflect user experience: availability, latency, and correctness are common.
3. Define the SLI precisely as good events divided by valid events, including what counts as "good" (e.g. status < 500 and latency < 300ms).
4. Set an SLO target based on user needs and historical performance, not aspiration. Start conservative.
5. Pick a rolling window (commonly 28 or 30 days) and a measurement source (load balancer logs, traces, synthetic probes).
6. Publish SLOs, dashboards, and the resulting error budget so engineering and product share one view.
7. Review SLOs quarterly and tighten or loosen them as the service and user expectations change.

Common Mistakes Teams Make When Ignoring This Practice

• Measuring server-side uptime instead of user-visible success.
• Setting 100% (or 99.999%) targets that are impossible or wasteful.
• Defining SLIs vaguely so two teams compute different numbers.
• Tracking dozens of SLOs nobody acts on.
• Treating SLOs as static after launch.

Tools and Techniques That Support This Practice

• Prometheus with recording rules and slo-style libraries (e.g. Sloth, Pyrra).
• Google Cloud Service Monitoring and SLO dashboards.
• Datadog, New Relic, and Grafana SLO features.
• OpenSLO for declarative, vendor-neutral SLO definitions.
• Synthetic monitoring tools for user-journey probes.

How This Practice Applies to Different Migration Types

• Cloud Migration: Define SLOs on the legacy platform first, then require the cloud target to meet or beat them before traffic shift.
• Database Migration: Add correctness and replication-lag SLIs to catch silent data issues during dual-write or cutover.
• SaaS Migration: Convert vendor SLA commitments into your own user-facing SLOs and verify against real traffic.
• Codebase Migration: Hold latency and error-rate SLOs steady across refactors so rewrites cannot silently regress reliability.

Checklist

• Critical user journeys identified
• SLIs defined as precise good/valid event ratios
• SLO targets set from user needs and history
• Rolling window and data source chosen
• SLO dashboards published and shared
• Error budget derived from each SLO
• Quarterly SLO review scheduled