Description
What is a service level objective (SLO)?
A service level objective (SLO) is a target value for a service level indicator, measured over a fixed window. It has three parts: the indicator (what is measured), the threshold (how good it must be) and the window (over what period). 'At least 99.5% of OTP send requests are accepted by the WhatsApp Cloud API within two seconds, measured over a rolling 28 days' is a complete SLO.
SLOs are internal. They describe the reliability a team intends to deliver and drive engineering decisions. A service level agreement (SLA) is different: an external contract with customers that names consequences, such as service credits, when it is missed. Because missing an SLA costs money, the SLO behind it is set tighter — an SLA of 99.5% might be backed by an internal SLO of 99.9% — so the team has room to react before the contract is breached.
The gap between perfect and the SLO is the error budget. A 99.9% SLO over 30 days allows 0.1% of events to be bad, which for a time-based availability SLO is about 43 minutes. Teams spend that budget on deploys, experiments and incidents they could not prevent; when it runs out, the agreed response — a release freeze, a reliability sprint — kicks in. That is what turns a number on a dashboard into a decision rule.
Key takeaways
- A service level objective (SLO) is an internal target on an SLI over a window, such as 99.5% of OTP sends accepted within two seconds over 28 days.
- An SLO is set tighter than any SLA, so the team reacts before a contractual promise with penalties is at risk.
- The error budget is 100% minus the SLO: 99.9% over 30 days allows about 43 minutes of complete outage.
- Never aim for 100%: each extra nine costs more, and users on mobile networks cannot tell the difference.
- An SLO only works if missing it changes behaviour, such as pausing risky releases until the budget recovers.
Mechanics
How does a service level objective (SLO) work?
step 1 — Pick the journeys that matter
List the customer-facing flows — login OTP, order updates, inbound chats reaching agents — and choose one SLI for each, based on what users would notice failing.
step 2 — Choose the window
A rolling 28 or 30 days is common: long enough to smooth noise, short enough that last month's incident eventually ages out. Calendar months suit SLAs and reporting.
step 3 — Set the threshold from data
Look at what the service actually delivered in recent months and what users tolerated. Set the SLO just below current performance if users are happy, above it if they are not — never at 100%.
step 4 — Agree the consequences
Write down what happens when the budget is spent — pause feature releases, prioritise reliability work, review alerts — and have product and engineering sign it off before it is needed.
step 5 — Alert on burn rate
Page when the error budget is being consumed fast enough to run out within hours or days, rather than on every individual error. A fast burn is the natural trigger for incident management.
step 6 — Review every quarter
Tighten or relax the SLO as the product, traffic and dependencies change, and retire SLOs nobody acts on.
Why it matters
Why does a service level objective (SLO) matter?
Reliability without a target is either neglected or gold-plated. An SLO gives developers and business owners a shared definition of 'reliable enough' for each journey — strict for OTPs and payments, looser for a weekly newsletter — so effort goes where customers notice it. It turns arguments about whether to ship or stabilise into a quick check of the remaining error budget, and it gives support and sales an honest ceiling for what to promise customers.
Properties
A service level objective (SLO): key facts and limits
- Three parts
- Indicator, threshold, window
- 99.9% over 30 days
- About 43.2 minutes of full outage
- 99.5% over 28 days
- About 3 h 22 min (201.6 minutes)
- 99.99% over 30 days
- About 4.3 minutes
- Typical window
- Rolling 28 or 30 days
- SLO vs SLA
- Internal target vs external contract with penalties
- Fast-burn page
- Burn rate 14.4 over 1 hour (2% of a 30-day budget)
Usage
A service level objective (SLO) in code
# slo/otp-send.yaml — reviewed and versioned like codeservice: whatsapp-senderslo: otp-send-latencydescription: OTP sends accepted by the Cloud API within 2 ssli:good: sends_total{journey="otp", outcome="ok", latency_le="2s"}valid: sends_total{journey="otp", outcome!="caller_error"}objective: 99.5 # percentwindow: 28d # rollingerror_budget_policy:- when: budget_remaining < 50%action: reliability review before risky releases- when: budget_remaining <= 0action: freeze feature releases until the budget recoversalerts:- burn_rate: 14.4 # whole budget gone in about 2 days at this paceover: 1hpage: true- burn_rate: 6over: 6hpage: true
A team-internal format: the indicator, objective, window, the policy for a spent budget and multi-window burn-rate alerts in one reviewed file.
Caveats
Common mistakes with a service level objective (SLO)
Setting the SLO equal to the SLA
Then the first warning you get is a contract breach. Keep the internal objective tighter so there is time to react.
Aiming for 100%
Perfect reliability is impossible and chasing it stalls delivery. Customers on mobile networks cannot tell 99.99% from 99.999%; pick the lowest target that keeps them happy.
An SLO with no consequences
If burning the error budget changes nothing, the SLO is decoration. Agree in advance what slows down or stops when it runs out.
Promising more than your dependencies allow
A send SLO is bounded by the platforms you call and the networks your customers use, and no amount of high availability engineering on your side lifts it above them. Measure the parts you control, design for dependency failures and leave margin.
Alerting on every error
Paging on single failures exhausts on-call without protecting the SLO. Alert on budget burn rate over a short and a long window instead.
Example
Example: Two SLOs for a Mumbai insurer
A Mumbai insurance company runs WhatsApp for policy OTPs and renewal reminders. It sets an OTP SLO of 99.5% of sends accepted within two seconds over 28 days — a budget of about 6,000 slow or failed sends on its 1.2 million monthly OTPs — and a looser 99% SLO for reminders, which can tolerate a delay. Its agreement with partner apps promises 99% for OTPs, leaving a cushion. When a bad deploy burns half the OTP budget in a day, the agreed policy freezes releases until a fix and a postmortem are done.
Notes
Best practices for a service level objective (SLO)
- Start with one SLO per critical journey and add more only when a real incident slipped through.
- Publish SLOs where support and sales can see them, so promises to customers stay below them.
- Use rolling windows for engineering decisions and calendar months for customer reports.
- Show the remaining error budget next to the release button.
Questions
SLO FAQs
- What is the difference between an SLO and an SLA?
- An SLO is an internal target; an SLA is an external contract with penalties. SLAs are usually looser than the SLOs behind them, so the team notices trouble before a customer can claim credits.
- Should an SLO be request-based or time-based?
- Request-based is usually better for APIs and message sends: the share of valid requests that were good, so a 99.9% SLO allows one bad send in a thousand wherever they fall. Time-based SLOs count bad minutes instead (99.9% over 30 days is about 43 minutes) and suit services whose traffic is too thin to count requests meaningfully.
- What is a good SLO for WhatsApp message sending?
- There is no universal number; set it from your measured performance and what each journey needs. OTPs usually get the strictest target, such as 99.5% accepted within two seconds, while marketing sends can use a looser one.
- What happens when an SLO is missed?
- Whatever the team agreed in its error budget policy — typically pausing risky releases and prioritising reliability work until the budget recovers. Missing an SLO carries no contractual penalty; missing an SLA does.