# Defining Service Level Objectives (SLOs) and Indicators (SLIs)

> Chapter 14 of the Courseiva GOOGLE-PCDOE curriculum — https://courseiva.com//learn/google-pcdoe/service-level-objectives-and-indicators

**Official objective:** 4.1 — Establish SLOs and SLIs for services, and use error budgets to balance reliability and feature velocity.

## Introduction

Defining Service Level Objectives (SLOs) and Service Level Indicators (SLIs) gives teams a clear, data-driven way to answer: "How reliable is our service, and how much time can we spend on new features without breaking it?" For the Google Professional Cloud DevOps Engineer exam, this concept is the foundation of the entire reliability engineering mindset — you will be tested on how to set targets, measure performance, and use error budgets to make trade-off decisions. Without understanding SLOs and SLIs, you cannot pass the reliability section of the PCDOE exam.

## The Coffee Shop Barista Analogy

A coffee shop's espresso machine is the central tool that defines the quality and speed of every drink the barista makes. 

The coffee shop owner defines a Service Level Indicator (SLI) as "the time from when a customer pays until they receive their latte." The owner and the barista agree on a Service Level Objective (SLO): "95% of all lattes must be handed over within 3 minutes during the morning rush." This is a measurable target for the shop's performance. 

Every morning, the barista tracks actual delivery times. If 98 out of 100 lattes arrive within 3 minutes, the shop meets its SLO. The remaining 2% that took 4 or 5 minutes are the error budget — the small amount of slow service the shop can tolerate. 

One day, the owner wants the barista to try a new, more complex latte decoration that adds 30 seconds per drink. The barista checks the error budget: the shop has only used 3% of its allowed 5% slow-service target this week. She has 2% error budget left — enough room to experiment with the decoration without breaking the SLO. If the decoration makes the SLO fail, they revert to the simpler style. This exactly mirrors how engineering teams use error budgets to balance new features against reliability. 

The SLI is the measurement (latte time). The SLO is the target (95% under 3 minutes). The error budget is the allowed failure (5% of orders can be slow). The barista uses the error budget to decide if she can safely introduce a creative new process.

## Core explanation

At its simplest, a Service Level Indicator (SLI) is a specific measurement of some aspect of your service's performance. Think of it as a single number on a dashboard. Common SLIs include "the percentage of HTTP requests that return a successful status code" (availability), "the time it takes for a server to respond to a request" (latency), or "the number of requests processed per second" (throughput). An SLI must be something you can actually count or measure — it is the raw data.

A Service Level Objective (SLO) is the target you set for that SLI. You decide, "I want my SLI value to be at least X% over a given time window." For example: "99.9% of all HTTP requests will return a successful status code over any rolling 30-day period." The SLO is your promise to yourself (and to your users) about the minimum acceptable level of service.

The Error Budget is the amount of failure you can tolerate and still meet your SLO. It is calculated as 100% minus your SLO target. If your SLO is 99.9% availability, your error budget is 0.1% of total possible downtime. If your service runs for 43,200 minutes in a month, 0.1% is 43.2 minutes of allowed failure. You can think of the error budget as your "reliability bank account" — you can spend it on risky changes, but once it is depleted, you must stop deploying new features and focus purely on stability.

These three concepts work together in a feedback loop. First, you decide what matters most to your users. This determines which SLIs you track. Second, you set SLO targets that reflect an acceptable level of service — not perfection, but good enough. Third, you measure your actual SLI performance against your SLO to see if you are within your error budget. Fourth, you use the error budget to make decisions: when the budget is high, you can push new features quickly; when it is low or exhausted, you slow down and fix reliability issues first.

Why does this matter? Without SLIs and SLOs, teams rely on gut feeling or anecdotal reports. A developer might think the service is "fine" because their one request worked, while 20% of users are hitting errors. SLOs give an objective, agreed-upon definition of "good enough." Error budgets depersonalise the tension between developers who want to ship code and operations teams who want stability. Instead of arguing, both teams look at the same number and agree on what to do next.

For the PCDOE exam, you must understand the four golden signals (though they are not directly tested as such, the concepts are essential):
- Latency: how long it takes to return a response
- Traffic: how many requests are hitting your system
- Errors: the rate of failed requests
- Saturation: how close your system is to running out of capacity

Google's Site Reliability Engineering (SRE) teams popularised this framework. The PCDOE exam tests your ability to apply these principles in Google Cloud services like Cloud Monitoring, where you can create SLI-based alerting policies and dashboards. You will need to know how to choose good SLIs (avoid vanity metrics like CPU usage that don't directly reflect user experience), set realistic SLOs (not 100%, which is impossible), and calculate error budgets correctly over rolling windows.

An SLI without an SLO is just a number. An SLO without an SLI is just a wish. The error budget is what turns this from theory into a practical decision-making tool for balancing feature velocity and reliability.

## Real-world context

An IT professional working at a video streaming service like a small Netflix competitor would start by asking: "What makes our users happy?" They decide the most important user-facing metric is that a video starts playing within 3 seconds of clicking play. They set this as their primary SLI: "the percentage of playback start requests that complete within 3 seconds."

Next, they gather historical data over the last three months. They see that 99.2% of starts were under 3 seconds. They decide a realistic SLO is 99% over a rolling 30-day window. This gives an error budget of 1% of total requests — meaning 1% of all playback start requests can be slower than 3 seconds. They implement this in Google Cloud Monitoring by creating a custom metric that tracks the latency of the first byte of video data sent to the user, then set up an alert that fires if the SLI drops below 99% for any 5-minute period.

The engineering team wants to deploy a new recommendation algorithm that might increase video load times slightly. Before approving the deployment, the on-call engineer checks the current error budget consumption:
- The service has been running for 25 days of the current 30-day window.
- The error budget consumed so far is 0.4% (meaning 0.4% of requests have been slow).
- The remaining error budget is 0.6% — plenty to absorb a small increase from the new algorithm.

The engineer approves the deployment and monitors the SLI. After two days, the SLI drops to 98.7%, exhausting the remaining error budget. The team immediately pauses all non-essential deployments and holds a war room to optimise the new algorithm. They revert the change, the SLI climbs back to 99.2%, and they restart the error budget clock for the next 30-day window.

In a more structured organisation, the IT professional also creates a monthly SLO report for management. This report includes:
- The actual SLI value for the month
- The error budget consumption rate
- How many deployments were blocked due to budget exhaustion
- A recommendation for whether the SLO target should be adjusted (e.g., if the team consistently exceeds 99.5%, they might raise the SLO to 99.9% to push for better reliability)

The key actions the IT professional takes daily include:
- Reviewing SLI dashboards in Google Cloud Monitoring
- Responding to SLO burn-rate alerts (alerts that predict error budget exhaustion within hours)
- Participating in a weekly SLO review meeting where teams present their error budget health
- Writing deployment approval policies that automatically reject changes when error budget is below a certain threshold
- Tuning SLIs to focus on user experience rather than internal system metrics

## Exam focus

The PCDOE exam tests your understanding of how to define, measure, and use SLIs, SLOs, and error budgets in practice. The questions are scenario-based and often present a service with a specific problem, then ask you to choose the correct SLI or SLO to fix it. The exam loves testing the difference between a good SLI (user-centric) and a bad SLI (infrastructure-centric).

Question types you will see:
- Given a description of a service (e.g., a database, a web application, a mobile backend), identify the most appropriate SLI to track user happiness.
- Given an SLO target and a measured SLI value, calculate whether the error budget is exhausted.
- Given a situation where the error budget is nearly exhausted, choose the correct action (always: stop deploying new features and focus on reliability).
- Given a scenario where a team insists on a 100% SLO, explain why that is impossible and what target is realistic.
- Identify which of the four golden signals (latency, traffic, errors, saturation) is being referenced in a given description.

Common traps the exam sets:
- Choosing an SLI that measures internal infrastructure (like CPU utilisation) instead of user-facing behaviour (like request latency). The exam wants you to pick SLIs that directly reflect the user's experience.
- Confusing availability (success percentage) with latency (response time). The exam describes a service that is down but fast when it is up — the correct SLI is availability, not latency.
- Setting an SLO of 100%. The exam presents this as an attractive option, but it is always wrong because 100% is mathematically impossible in any distributed system.
- Misinterpreting the error budget as a "per-month" allowance rather than a rolling window. The exam tests that the error budget is calculated over a specific time period (commonly 30 days).
- Thinking that an SLO defines what is good enough for the user, not what is possible for the system. The exam asks you to set SLOs based on user expectations, not on current technical limitations.

Key concepts to memorise for the exam:
- SLI: the measurement. Example: "proportion of requests with latency below 500ms."
- SLO: the target. Example: "99.9% of requests will have latency below 500ms over 30 days."
- Error budget: 100% - SLO. Example: 0.1% allowed failure.
- The error budget is consumed when the SLI falls below the SLO.
- When the error budget is exhausted, the team must stop shipping features and focus on reliability.
- Good SLIs focus on the user journey, not on server health.
- Always use a rolling time window (e.g., 30 days) for SLO calculation, not a calendar month.
- The four golden signals: latency, traffic, errors, saturation.
- Burn rate: how fast the error budget is being consumed. A burn rate above 1 means you will exhaust the budget before the window ends.

## Step by step

1. **Identify User-Centric SLIs** — List what matters most to your users: is it that pages load quickly (latency), that they never see an error (availability), or that they can always upload a file (throughput)? Choose 3-5 measurable indicators that directly reflect user happiness, not server statistics.
2. **Define the SLO Target** — Decide what percentage of requests should meet your SLI over a specific rolling window (usually 30 days). For example: '99.9% of all HTTP requests will return a 200 status code within 500ms over a rolling 30-day period.' This target must be realistic but challenging.
3. **Calculate the Error Budget** — Subtract your SLO percentage from 100% to get the error budget. If your SLO is 99.9%, your error budget is 0.1%. If your service has 1,000,000 requests in a month, your error budget is 1,000 requests that can fail or be slow without breaking the SLO.
4. **Implement Monitoring and Alerting** — Set up Google Cloud Monitoring (or similar tools) to track your SLI in real-time. Create an alert that triggers a notification when the error budget consumption rate (burn rate) suggests you will exhaust the budget before the window ends.
5. **Use the Error Budget for Deployment Decisions** — Check the current error budget before approving any risky deployment. If the budget is above a safety threshold (e.g., 50% remaining), you can deploy. If it is low or exhausted, delay the deployment and fix the root cause of the budget consumption first.

## Comparisons

### Service Level Indicator (SLI) vs Service Level Objective (SLO)

**Service Level Indicator (SLI):**
- Raw measurement of service performance
- For example, '99.2% of requests succeeded'
- Focuses on what is actually happening

**Service Level Objective (SLO):**
- Target for that measurement
- For example, '99.9% of requests must succeed'
- Focuses on what you want to happen

### Error Budget vs Service Level Agreement (SLA)

**Error Budget:**
- Internal allowance for failure
- Calculated as 100% - SLO
- Used for deployment decisions

**Service Level Agreement (SLA):**
- Formal contract with penalties
- Defined between provider and customer
- Used for legal and financial accountability

### User-Centric SLI vs Infrastructure-Centric Metric

**User-Centric SLI:**
- Measures directly from user perspective
- Example: page load time
- Preferred for SLO setting

**Infrastructure-Centric Metric:**
- Measures internal system health
- Example: CPU usage
- Useful for operations but not for SLOs

### Rolling Window vs Calendar Month

**Rolling Window:**
- Continuously slides forward (e.g., last 30 days)
- Avoids end-of-month spikes
- Recommended for SLO calculation

**Calendar Month:**
- Fixed start and end dates
- Can cause uneven error budget consumption
- Discouraged for SLOs

## Common misconceptions

- **Misconception:** An SLO of 100% is a good target because it guarantees perfect service. **Reality:** 100% SLO is impossible in distributed systems due to network failures, software bugs, and planned maintenance. Realistic SLOs are 99.9%, 99.99%, or 99.999% (called "nines"). (Sales and marketing teams often promise perfect uptime, but engineers know no system can achieve 100% reliability without users noticing extreme costs and delays.)
- **Misconception:** The error budget is only used to decide when to roll back a change that caused an outage. **Reality:** The error budget is used proactively to decide whether to deploy any risky change in the first place. It governs all feature velocity, not just post-mortems. (Beginners think the error budget is a reactive tool, but it is actually a proactive throttle on deployment risk.)
- **Misconception:** An SLI is the same as an SLO. **Reality:** An SLI is the actual measured value (e.g., 99.8% of requests succeed), while an SLO is the target you set (e.g., 99.9% of requests must succeed). They are completely different concepts. (The acronyms sound similar, and many introductory articles use them interchangeably, causing beginners to blur the distinction.)
- **Misconception:** You should track as many SLIs as possible to be thorough. **Reality:** You should track only a few essential, user-facing SLIs. Too many SLIs create noise and dilute focus. Google recommends tracking 3-5 key SLIs. (Beginners think more data is always better, but in SRE, creating SLIs for everything leads to alert fatigue and confusion about what actually matters.)

## Key takeaways

- Service Level Indicators (SLIs) are raw measurements of your service's behaviour, such as request latency or error rate.
- Service Level Objectives (SLOs) are the accepted targets for those SLIs, defined as a percentage over a rolling time window.
- The error budget is calculated as 100% minus your SLO target and represents the amount of failure your service can tolerate.
- When the error budget is exhausted, the team must stop all non-critical feature deployments and focus on improving reliability.
- Good SLIs are directly tied to user experience, not to internal system metrics like CPU usage or memory utilisation.
- An SLO of 100% is impossible and always the wrong answer in any PCDOE exam question about realistic targets.
- Choose an SLO based on what users (or customers) expect, not on what your current system can achieve without improvement.

## FAQ

**What is the difference between an SLA and an SLO?**

An SLA (Service Level Agreement) is a formal contract between a provider and a customer that specifies penalties if reliability targets are missed. An SLO (Service Level Objective) is an internal target you set for yourself. SLAs are usually defined using SLOs, but SLOs can be stricter than the SLA.

**How do I calculate the error budget for a service?**

The error budget is 100% minus your SLO percentage. If your SLO is 99.9% over 30 days, your error budget is 0.1% of that period. For a 30-day, 24/7 service, 0.1% is 43.2 minutes of allowed downtime or slow performance.

**Can I have different SLOs for different parts of my service?**

Yes. You can define separate SLOs for different user-facing features, such as a strict SLO for the checkout page and a looser SLO for the product recommendation widget. Each SLO has its own error budget.

**What should I do when my error budget is completely exhausted?**

Stop all non-critical feature deployments and focus entirely on reliability improvements or bug fixes. You should also consider rolling back recent changes that contributed to the exhaustion.

**Is CPU utilisation a good SLI?**

No. CPU utilisation is an infrastructure metric that does not directly reflect user experience. Good SLIs focus on user-facing behaviour, such as request latency, error rate, or uptime from the user's perspective.

**How do I decide what SLO target to set for a new service?**

Start by measuring the service's current SLI over a baseline period (e.g., 2-3 months). Then set the SLO slightly above the actual performance to push for improvement, but not so high that it is unachievable. For a brand new service, you might start with a looser SLO like 99% and tighten it as you gain confidence.

---

Interactive version with quiz and diagrams: https://courseiva.com//learn/google-pcdoe/service-level-objectives-and-indicators