Say it like this
- We need to meet our SLO for this quarter
- This incident violated our SLO
- What is our current SLO for API latency?
Use it at work
Setting goals
- Our SLO is 99.9% of requests under 300 ms.
- Let's define an SLO for the search service.
Monitoring
- We're burning through our SLO.
- The SLO dashboard is red.
Decisions
- We're below the SLO, so let's pause risky releases.
- Should the SLO be stricter than the SLA?
Don't say this
SLOs are internal goals, not legal agreements. SLAs are formal contracts.
Don't mix it up
| Term | What it is | Who writes or uses it | When |
|---|---|---|---|
| SLO | Internal reliability target | SRE | Monitoring |
| SLA | Promise to customers | Sales, legal | Contracts |
| error budget | Allowed failure under the SLO | SRE | Release decisions |
Practice
Try it
4 quick exercises
1. Your service had unexpected downtime. A colleague asks about the impact. What do you say?
2. Before deploying this feature, we should _______ what the _______ is for page load time.
3. Which sentence uses SLO incorrectly?
4. Rewrite this in natural tech English using SLO: 'We want our search to be really fast, like it should give answers in under half a second most of the time.'
Say it out loud
Phrase 1 of 3
"We need to meet our SLO for this quarter"
We don't save your recording. The word check uses your browser's speech recognition.
More about SLO
Real examples(3)
- in a standup
"We breached our SLO yesterday due to the database performance issue, so we're prioritizing optimization this sprint."
- in a code review
"This change might impact our SLO, so we need to add monitoring before merging."
- in a team meeting
"Our payment service SLO is 99.95% availability, which means we can afford less than 22 minutes of downtime per month."
More mistakes(2)
Handle with care. SLO is often confused with SLA (Service Level Agreement). An SLO is a goal or target, while an SLA is a formal contract. Do not use SLO when referring to legal agreements.
- ✕Our SLO is 99% uptime or we lose money.✓Our SLA is 99% uptime or we lose money. Our SLO is 99.5% uptime.
Penalties and financial consequences belong to an SLA, not an SLO.
- ✕We do not need an SLO for this small service.✓We should define an SLO even for small services to clarify reliability expectations.
SLOs are useful for all services to set clear expectations and guide prioritization.
Other forms(2)
- SLO noun
"Our authentication service has an SLO of 99.99% availability."
- SLOs noun
"We need to document all SLOs in our internal wiki."
Often used with(5)
- meet/miss an SLO · Used to describe whether a service achieves or fails to achieve its target
- breach an SLO · Similar to missing an SLO; indicates failure to meet the objective
- define/set an SLO · Used when establishing a new reliability target for a service
- SLO violation · An incident where the service fails to meet its stated objective
- SLO-driven · Describing work or decisions that are guided by SLO targets
Similar words(3)
- Service Level Objective · The full name; SLO is the abbreviation
- reliability target · A less formal term for the same concept
- performance goal · Broader term that includes SLOs and other performance metrics
Opposites(2)
- SLA (Service Level Agreement)
- best effort (no specific target)
Questions(6)
- What is the full form of SLO?
- SLO stands for Service Level Objective. It is a measurable goal that specifies how well a service should perform, such as uptime percentage or response time targets.
- What is the difference between SLO and SLA?
- An SLO (Service Level Objective) is an internal goal that a team sets for service performance. An SLA (Service Level Agreement) is a formal contract between a company and its customers that specifies what happens if performance targets are not met, often including financial penalties. SLOs guide internal priorities, while SLAs are binding legal agreements.
- Why are SLOs important in software engineering?
- SLOs are important because they help teams balance reliability with feature development. They establish clear expectations about how well a service should perform, guide resource allocation, and provide metrics for measuring success. SLOs also help teams respond appropriately to incidents and communicate service status to stakeholders.
- What are common metrics used in SLOs?
- Common SLO metrics include availability (percentage of time the service is accessible), latency (response time), throughput (requests processed per second), and error rate (percentage of failed requests). Different services may have different critical metrics depending on their purpose.
- How do you write a good SLO?
- A good SLO should be specific and measurable (not vague), achievable but challenging, aligned with user needs and business goals, and based on historical performance data. For example, 99.9% availability is better than just saying the service should be reliable.
- Is SLO formal or informal?
- SLO is formal professional terminology used in engineering discussions, documentation, and meetings. While you might hear it in casual conversation among engineers, it is primarily used in formal contexts like incident reports, planning meetings, and official service documentation.
