Service Level Agreements

In modern digital systems, uptime isn't just a technical goal—it’s a business imperative. Service Level Agreements (SLAs) are the formal contracts that codify these reliability promises, translating technical performance into business accountability. For engineers and product managers, mastering the framework of SLAs, SLOs, and SLIs is essential for building trust with users and making informed, data-driven decisions about where to invest engineering effort.

Defining the Reliability Hierarchy: SLA, SLO, and SLI

To manage reliability systematically, you must understand the distinct roles of three interconnected concepts. At the top is the Service Level Agreement (SLA), a binding contract between a service provider and its customers. It defines the minimum level of service promised and includes consequences, typically financial penalties like service credits, for failing to meet those commitments. The SLA is an external-facing business and legal document.

The Service Level Objective (SLO) is an internal target for service reliability. It’s the specific, measurable goal your team aims to achieve, which is almost always more aggressive than the SLA promise. For instance, your SLA might promise 99.5% availability monthly, but your internal SLO could be 99.9%. This gap, known as an error budget, provides a buffer for incidents and planned work without violating the customer contract. SLOs are the crucial link between business promises and engineering work.

To know if you are meeting your SLO, you need to measure it. This is the role of the Service Level Indicator (SLI), a quantitative measure of a service’s performance over time. An SLI is essentially a carefully defined metric. Common SLIs measure availability (the proportion of successful requests), latency (how long requests take), throughput (how much work is done), and error rate (the proportion of failed requests). An SLI becomes meaningful only when paired with a measurement window (e.g., "over 30 days") and an aggregation method (e.g., averaging across all service instances).

Selecting and Implementing Effective SLIs

Not all metrics are good SLIs. A well-chosen SLI is representative of user happiness, is measurable with high fidelity, and aligns with business goals. For a user-facing web service, measuring availability as the ratio of successful HTTP requests (e.g., status codes 200 and 404 are "successful" for measurement, while 500 is a "failure") is a standard approach. For latency, you often use a percentile-based SLI, such as the 90th or 99th percentile response time, rather than the average, as it reveals the experience of your slowest users.

The implementation requires robust instrumentation. You need to collect raw data—like request counts and durations—from your serving infrastructure, then aggregate it to compute the SLI. For availability, the formula is typically:

$$\text{Availability}=\frac{\text{Successful requests}}{\text{Total requests}}\times 100\%$$

This calculation must run continuously over your defined rolling window (e.g., the last 28 days). It’s critical that your SLI measurement closely mirrors the user's actual experience; measuring from a load balancer’s perspective is better than from deep within your backend, where it might miss failures in the networking path.

Calculating and Leveraging Your Error Budget

The concept of the error budget is what makes SLOs a powerful tool for engineering management. It is calculated simply as:

$$\text{Error Budget}=1-\text{SLO}$$

If your SLO is 99.9% availability for a month, your allowed error rate is 0.1%. This translates into a specific amount of "unsuccessful" time. For a 30-day (720-hour) month, your error budget is:

$$720\text{ hours}\times 0.001=0.72\text{ hours, or }43.2\text{ minutes}$$

This 43.2 minutes is your budget for unreliability. Any incident consuming this time is "spending" the budget. Once the budget is exhausted, your focus must shift entirely to improving reliability until the budget is replenished in the next window. Conversely, if you have budget remaining, you have clear permission to take risks, such as deploying new features or performing risky migrations. The error budget thus operationalizes reliability, transforming it from an abstract goal into a concrete resource to be managed.

Monitoring Compliance and Driving Action

Effective SLO governance requires real-time monitoring and clear decision-making processes. You need a dashboard that shows your current SLI measurement against your SLO target and visualizes the burn rate of your error budget. Setting up alerts on rapid budget burn, rather than just instantaneous SLI violations, helps you respond to emerging incidents before the entire budget is depleted.

The ultimate goal is to use this data to make smarter prioritization decisions. If a service is consistently consuming its error budget, the data provides an unambiguous case for dedicating resources to stability work, refactoring, or capacity planning. For a service with ample budget, you can confidently prioritize velocity and innovation. This creates a balanced, sustainable pace for engineering teams, moving reliability discussions from emotional arguments to objective, data-driven negotiations.

Common Pitfalls

Picking SLIs That Don’t Reflect User Experience. A common mistake is measuring backend server uptime instead of successful end-user requests. A server can be "up" but returning errors or timeouts due to a database failure, making the user experience poor while your SLI shows green. Always define your SLI from the user’s perspective.

Setting SLOs Without Historical Data or Business Context. Setting an SLO of "four 9s" (99.99%) because it sounds good is a recipe for failure. Start by measuring your current reliability for several weeks to establish a baseline. Then, align the SLO with the actual business criticality of the service. The SLO for an internal testing tool can be lower than for your customer-facing payment API.

Treating the SLO as a Performance Target. The SLO is not a target to be maximized but a threshold to be managed. If you are consistently far better than your SLO (e.g., achieving 99.999% against a 99.9% SLO), you may be over-investing in reliability at the expense of innovation. Consider cautiously relaxing the SLO to free up an error budget for new work, or investigate if you are measuring the right thing.

Neglecting to Communicate and Review. SLOs are not a "set and forget" exercise. Failing to regularly review them with stakeholders—both engineering teams and business owners—leads to misalignment. As service architecture and user behavior evolve, your SLIs and SLOs may need to evolve too. Schedule quarterly reviews to ensure they remain relevant and useful.

Summary

• A Service Level Agreement (SLA) is an external contract with penalties, a Service Level Objective (SLO) is an internal reliability target, and a Service Level Indicator (SLI) is the specific metric used to measure performance.
• Effective SLIs, such as availability and latency percentiles, must be defined from the user’s perspective and implemented with robust instrumentation to accurately reflect the experience.
• The error budget, derived from your SLO (1 – SLO), quantifies allowed unreliability and is a crucial management tool for balancing the pace of innovation with the need for stability.
• Monitoring SLO compliance and error budget burn rate enables proactive incident response and provides objective data for prioritizing engineering work between new features and reliability improvements.
• Avoiding common pitfalls—like poorly chosen SLIs or static SLOs—requires grounding targets in historical data, aligning them with business needs, and reviewing them regularly with all stakeholders.