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.
Jump to a section
A simple way to picture Defining Service Level Objectives (SLOs) and Indicators (SLIs)
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
These come up on the exam all the time. Here's how to tell them apart.
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
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
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
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
Mistake
An SLO of 100% is a good target because it guarantees perfect service.
Correct
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.
Mistake
The error budget is only used to decide when to roll back a change that caused an outage.
Correct
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.
Mistake
An SLI is the same as an SLO.
Correct
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.
Mistake
You should track as many SLIs as possible to be thorough.
Correct
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.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
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.
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.
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.
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.
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.
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.
You've finished Defining Service Level Objectives (SLOs) and Indicators (SLIs). Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?