A service dashboard shows:
CPU:
42%
memory:
61%
Pods ready:
3 of 3
database:
available
Every component appears healthy.
Customers still cannot complete checkout.
The order service accepts requests.
The payment service responds.
The database is online.
But successful checkout now takes twenty seconds, and a growing number of customers abandon the process.
The infrastructure is running.
The service is not providing the experience its users depend on.
This is the gap service-level objectives help expose.
A traditional operational statement might say:
The service should be highly available.
That sounds reassuring.
It does not tell us:
- which user activity matters
- what counts as success
- how quickly success must occur
- how much failure is acceptable
- over which period reliability is measured
- what the team should do when reliability deteriorates
An SLO turns that ambition into a testable statement.
For example:
Over a rolling 28-day period, 99.9% of valid checkout requests should complete successfully within four seconds.
That statement gives the team something concrete to measure.
It identifies:
- the user journey
- the success condition
- the latency expectation
- the reliability target
- the measurement window
It also accepts an uncomfortable truth.
The target is not 100%.
Some failure is expected.
That is not a lack of ambition.
It is an acknowledgement that reliability has a cost, and that engineering time must also support:
- new features
- security improvements
- platform upgrades
- cost reduction
- architectural change
An SLO turns reliability into an engineering decision by defining the level of service users should be able to depend on and the amount of failure the system may consume before reliability work must take priority.
The objective gives the team a shared boundary between acceptable risk and urgent corrective action.
Reliability needs a user
A server can be running while the service is unusable.
A Pod can be ready while every request fails.
A database can accept connections while an important query takes thirty seconds.
A queue can be available while messages wait for several hours.
This means reliability cannot be defined only through component health.
COMPONENT VIEW
Are the servers running?
Are the Pods ready?
Is the database reachable?
USER VIEW
Can I complete the action
I came here to perform?
An SLO should begin with a user or consumer.
That consumer may be:
- a customer
- another service
- an application developer
- an incident responder
- an internal platform user
For bfstore, important user journeys might include:
browse the product catalog
add an item to a basket
complete checkout
receive an order confirmation
publish a new service version
retrieve application telemetry
Each journey depends on several technical components.
The user does not care whether the failure originated in:
- Kubernetes
- MySQL
- Kafka
- DNS
- a deployment pipeline
- a service dependency
The user experiences one outcome:
the operation worked
or
the operation did not work
A useful reliability objective should stay close to that outcome.
SLIs provide the measurement
An SLO needs a service-level indicator.
The SLI is the measurement used to evaluate the service experience.
A common form is:
good events
───────────
total valid events
For checkout:
successful checkout requests
────────────────────────────
valid checkout requests
Suppose bfstore receives 100,000 valid checkout attempts during the measurement window.
If 99,930 complete successfully within the required time:
good events:
99,930
total valid events:
100,000
reliability:
99.93%
The SLI reports observed performance.
The SLO defines the target.
SLI
What level of service
did users actually receive?
SLO
What level of service
should users be able to depend on?
Without a reliable SLI, the objective is only a sentence.
Without an SLO, the indicator is only a number without a decision boundary.
SLIs, SLOs and SLAs are different
These terms are related but serve different purposes.
Service-level indicator
The SLI is the measurement.
99.93% of valid checkout requests
completed successfully within four seconds.
Service-level objective
The SLO is the internal reliability target.
At least 99.9% of valid checkout requests
should complete successfully within four seconds
over a rolling 28-day window.
Service-level agreement
An SLA is a formal agreement with consequences.
It may define:
- contractual commitments
- service credits
- financial penalties
- escalation procedures
- exclusions
SLI
measured performance
SLO
engineering objective
SLA
external commitment
with consequences
An organisation may choose an internal SLO that is stricter than its external SLA.
That creates safety margin.
EXTERNAL SLA
99.5%
INTERNAL SLO
99.9%
The team can respond before the contractual boundary is threatened.
SLOs are primarily tools for engineering and operational decision-making.
They should not be selected merely by copying a contractual number into a dashboard.
One hundred per cent is not a neutral target
A target of 100% sounds ideal.
It also means:
acceptable failures:
zero
No failed requests.
No unavailable dependency.
No rollout interruption.
No maintenance impact.
No lost packet that becomes visible to the user.
No regional disruption.
No human error.
Maintaining that promise may require enormous expense and severely restrict change.
HIGHER RELIABILITY TARGET
│
├── more redundancy
├── more testing
├── slower changes
├── greater capacity
├── more operational work
└── higher cost
Users may not need the maximum technically possible reliability.
A development environment does not require the same objective as production checkout.
A recommendation widget does not necessarily require the same reliability as payment authorisation.
The correct question is not:
How close can we get to 100%?
It is:
Which level of reliability is valuable enough to justify its engineering and operational cost?
This makes reliability a product decision as well as a technical one.
Reliability targets should reflect consequences
Different services create different failure consequences.
If the review service becomes unavailable for ten minutes:
customers cannot submit reviews
If the payment service becomes unavailable:
customers cannot complete purchases
If the order service loses accepted orders:
customers may be charged
without receiving an order
These outcomes do not deserve identical objectives.
A reliability target should consider:
- user impact
- financial impact
- data integrity
- regulatory requirements
- recovery difficulty
- available alternatives
- duration sensitivity
A non-critical recommendation may degrade gracefully:
recommendation unavailable
product page still works
The system can omit the recommendations and continue serving the primary journey.
A failed payment authorisation cannot be treated as casually.
PAYMENT FAILURE
may block checkout
or create uncertain financial state
SLOs should follow the importance of the capability rather than the enthusiasm of the team operating it.
Availability is more than uptime
Availability is often described as:
time available
──────────────
total time
This can be useful for continuously running systems.
For request-driven services, event-based measurement is often closer to the user experience:
successful requests
───────────────────
valid requests
A service may be technically available for an entire hour while failing 20% of requests.
A time-based probe that runs once per minute might miss the pattern.
PROBE VIEW
service responded every minute
REQUEST VIEW
one in five customers failed
The measurement method should match the experience being protected.
Possible availability SLIs include:
- successful request ratio
- successful job ratio
- successful message-processing ratio
- successful environment-provisioning ratio
- successful data-recovery ratio
The word available needs an operational definition.
Latency is part of reliability
A request that eventually succeeds may still fail the user.
Suppose checkout completes after thirty seconds.
Technically:
status:
successful
From the customer’s perspective:
experience:
unusable
An SLI can combine correctness and latency:
good request:
request succeeds
AND
duration <= 4 seconds
This avoids celebrating slow success.
Latency objectives are often expressed using thresholds:
99% of valid requests
complete within 500 milliseconds
or percentiles:
p99 latency:
below 500 milliseconds
The threshold-based good-event model fits naturally with error budgets:
requests within threshold:
good
requests above threshold:
bad
The threshold should represent a meaningful user boundary.
A target chosen only because the current system already meets it does not guide engineering.
A target chosen without considering real user behaviour may be equally decorative.
Percentiles reveal the tail
Average latency can hide severe slowdowns.
Suppose ten requests take:
100 ms
100 ms
100 ms
100 ms
100 ms
100 ms
100 ms
100 ms
100 ms
4,000 ms
The average is:
490 ms
That number does not reveal that one user waited four seconds while most waited one tenth of a second.
Percentiles describe the distribution.
p50
half of requests were faster
p95
95% of requests were faster
p99
99% of requests were faster
Tail latency matters because a distributed request may depend on several services.
A checkout workflow might call:
- basket
- catalog
- inventory
- payment
- order storage
A slow dependency can extend the entire journey.
CHECKOUT
│
├── basket
├── inventory
├── payment
└── order
The user experiences the combined path, not the average speed of each component viewed separately.
The denominator needs care
An SLI ratio depends heavily on what counts as a valid event.
Suppose a customer submits malformed input.
The service correctly returns:
InvalidArgument
Should that count as a reliability failure?
Usually not.
The system behaved according to its contract.
The denominator might include:
valid requests
while excluding:
- malformed input
- unauthenticated callers
- unsupported operations
- deliberate client cancellation
But exclusions can become dangerous.
A team could improve its reliability number by classifying more failures as invalid.
FAILED REQUEST
│
▼
RECLASSIFY AS EXCLUDED
│
▼
SLO LOOKS HEALTHIER
The eligibility rules should be:
- documented
- stable
- reviewed
- testable
A request should not move in or out of the denominator merely because the month has been particularly lively.
Measurement should be close to the user
An SLI can be measured at several points.
For a web request:
application
gateway
load balancer
synthetic probe
client
Each sees something different.
An application may record successful processing but miss a failure between the gateway and the customer.
A load balancer may see status codes but not know whether the business operation completed correctly.
A client-side signal may best represent user experience but be harder to collect reliably.
CLOSER TO APPLICATION
more implementation context
less complete user perspective
CLOSER TO USER
better experience signal
less internal detail
A strong design may use more than one layer:
- gateway metrics for request availability
- application spans for failure diagnosis
- synthetic checks for end-to-end validation
- business events for completed outcomes
The SLO should use the most trustworthy measurement of the promise being made.
Observability signals then explain why the objective is being missed.
The measurement window changes the meaning
An SLO needs a time window.
Possible windows include:
- calendar month
- rolling 7 days
- rolling 28 days
- rolling 30 days
- rolling quarter
A calendar window resets at a fixed boundary.
1 September
to
30 September
A rolling window continuously moves.
last 28 days
from the current moment
Rolling windows provide a consistent recent view.
Calendar windows may align more naturally with reporting or contractual periods.
The choice affects behaviour.
A calendar-month budget can encourage strange incentives near the boundary:
30 September
budget almost exhausted
1 October
budget fully restored
The system did not suddenly become reliable at midnight.
Only the accounting period changed.
Rolling windows reduce that cliff, though they can be harder to explain.
The target creates an error budget
An SLO below 100% permits a bounded amount of failure.
That permitted failure is the error budget.
For a 99.9% objective:
reliability target:
99.9%
error budget:
0.1%
If the window contains 1,000,000 eligible requests:
permitted bad events:
1,000
If the SLO is measured using time over 30 days, 99.9% availability allows approximately:
43 minutes and 12 seconds
of unavailability.
Higher targets reduce the budget quickly.
99%:
about 7 hours 12 minutes
99.9%:
about 43 minutes 12 seconds
99.99%:
about 4 minutes 19 seconds
These figures make the operational consequences easier to understand.
The difference between the targets is not merely an extra nine.
It is a substantially smaller tolerance for failure.
The error budget is not planned downtime
An error budget does not mean:
We are allowed to break production
for 43 minutes.
It means the system can experience that amount of user-visible failure before the objective is missed.
The budget may be consumed by:
- deployments
- infrastructure failures
- software defects
- dependency outages
- capacity shortages
- operational mistakes
- network problems
A team should not try to spend every remaining second deliberately.
The budget is a risk allowance.
ERROR BUDGET
space for change and uncertainty
within the promised reliability level
A healthy remaining budget indicates that the service can tolerate some continued delivery risk.
A rapidly disappearing budget indicates that reliability work may need to take priority.
Error budgets connect reliability to delivery
Without an error budget, discussions often become subjective.
The product team says:
We need to release product team says:
.
The operations team says:
The service is unstable.
The argument lacks a shared decision boundary.
An error-budget policy can say:
BUDGET HEALTHY
continue ordinary delivery
BUDGET BURNING RAPIDLY
investigate and reduce risk
BUDGET EXHAUSTED
pause risky changes
and prioritise recovery
This does not eliminate judgement.
It creates common evidence.
A policy might define:
- which changes may continue
- which changes require additional review
- when feature releases pause
- which reliability work becomes mandatory
- who can approve an exception
The SLO becomes operational only when the organisation agrees what to do with the result.
A dashboard without a decision policy is an attractive weather instrument in a building with no doors.
Burn rate shows how quickly the budget is disappearing
The current compliance percentage can move slowly.
A severe incident may be consuming the budget rapidly before the rolling SLO falls below target.
Burn rate compares the current rate of bad events with the rate permitted by the SLO.
burn rate = 1
means the service is consuming budget at exactly the sustainable rate.
burn rate > 1
means it is consuming budget too quickly.
burn rate = 10
means the service is burning budget ten times faster than the objective permits.
This helps detect dangerous conditions early.
HIGH BURN RATE
small amount of time
large amount of budget consumed
Alerting on burn rate focuses attention on threats to the reliability promise rather than every isolated failure.
Fast and slow burns need different alerts
A catastrophic outage and a gradual degradation can both exhaust the budget.
They require different detection windows.
Fast burn
large failure rate
short time
Example:
80% of checkout requests failing
during the last ten minutes
This needs urgent response.
Slow burn
smaller failure rate
longer time
Example:
1% of checkout requests failing
for several days
The immediate impact may look modest.
The cumulative budget damage can still be serious.
A robust alerting model uses multiple windows:
SHORT WINDOW
detect sudden severe failure
LONG WINDOW
confirm sustained budget impact
This reduces alerts for brief harmless spikes while still catching persistent degradation.
SLO alerts should be actionable
An alert should indicate that the reliability objective is at risk and that someone should take a meaningful action.
Weak alert:
CPU above 70%
High CPU may be harmless.
The service could still be healthy.
Stronger reliability alert:
Checkout availability error budget
is burning 12 times faster than permitted.
This connects the alert to user impact.
Component metrics remain useful for diagnosis.
SLO ALERT
tells us users are being affected
CPU, MEMORY, DATABASE AND TRACE SIGNALS
help explain why
This creates a useful hierarchy:
USER IMPACT
│
▼
RELIABILITY ALERT
│
▼
DIAGNOSTIC TELEMETRY
│
▼
ROOT CAUSE
Observability should help operators move from symptom to explanation.
It should not require them to infer user harm from a flock of unrelated infrastructure alarms.
One service may need several SLOs
A single availability number may not describe the complete service.
The checkout journey may need objectives for:
- availability
- latency
- correctness
- data durability
- notification delay
For example:
AVAILABILITY
99.9% of valid checkout attempts
complete successfully
LATENCY
99% of successful checkout attempts
complete within four seconds
ORDER INTEGRITY
99.999% of acknowledged orders
remain recoverable
CONFIRMATION
99% of accepted orders
produce a confirmation within one minute
Each protects a different user expectation.
Too many objectives can make the system difficult to operate.
The team should select a small number representing the most important promises.
FEW MEANINGFUL SLOs
guide decisions
MANY DECORATIVE SLOs
create dashboard wallpaper
An SLO should exist because crossing its boundary changes what the team does.
Component SLOs should support journey SLOs
The checkout journey depends on several services.
Each team may define a local SLO.
basket:
99.95%
inventory:
99.95%
payment:
99.99%
order:
99.95%
These do not automatically guarantee the checkout objective.
The combined journey may be less reliable than any individual component because every required dependency creates another opportunity for failure.
CHECKOUT SUCCESS
requires
basket success
AND
inventory success
AND
payment success
AND
order success
Local SLOs should be derived from or aligned with the end-to-end journey.
Otherwise each component can meet its own target while the customer-facing service misses its promise.
Platform and service teams need to understand how their reliability budgets compose.
Dependencies consume reliability too
A service may rely on an external provider.
Suppose bfstore payment processing depends on a provider offering lower reliability than the checkout target requires.
No amount of local Pod readiness can remove that dependency risk.
Possible responses include:
- choosing a stronger provider
- using multiple providers
- degrading gracefully
- queuing work safely
- changing the product promise
- improving recovery after uncertain outcomes
DEPENDENCY RELIABILITY
│
▼
LIMITS POSSIBLE SERVICE RELIABILITY
An SLO makes this architectural constraint visible.
The team can then decide whether the dependency design supports the intended promise.
Reliability cannot be negotiated solely inside the application repository.
Low traffic makes ratios noisy
Suppose an internal service receives ten requests during one hour.
One failure produces:
90% reliability
That appears catastrophic.
The sample is very small.
For low-volume services, teams may need:
- longer windows
- synthetic requests
- task-based measurements
- absolute failure thresholds
- careful alerting
HIGH TRAFFIC
ratios stabilise quickly
LOW TRAFFIC
individual events dominate
The SLO can remain valid.
The detection and alerting model needs to account for volume.
A low-traffic production recovery API may be extremely important despite receiving few requests.
It should not be ignored merely because it produces an inconvenient denominator.
Synthetic checks can protect quiet journeys
Some user journeys occur too infrequently to produce timely measurements.
A synthetic check can exercise the path deliberately.
For example:
create test basket
add test product
begin test checkout
verify expected response
clean up test state
Synthetic checks can detect:
- broken routing
- invalid certificates
- failed authentication
- missing dependencies
- deployment mistakes
They do not fully reproduce real users.
Synthetic traffic may use:
- different data
- different credentials
- different geography
- simplified workflows
It should complement real-event indicators rather than replace them automatically.
A synthetic check proves that one controlled journey worked from one controlled viewpoint.
Maintenance should not disappear casually
A team may be tempted to exclude maintenance windows from its SLO.
Sometimes exclusions are justified.
For example, a service may have a clearly communicated operational window.
But excluding every planned change creates a misleading objective.
UNPLANNED FAILURE
counts
PLANNED USER IMPACT
does not count
Users experience both.
A deployment that makes checkout unavailable is still a reliability event from the customer’s perspective.
The better design is often to make maintenance non-disruptive through:
- redundancy
- rolling deployment
- graceful draining
- migration planning
- backwards-compatible change
Exclusions should represent genuine contract boundaries, not a cupboard where avoidable outages are stored until the dashboard becomes green again.
SLOs should guide architecture
Suppose bfstore defines:
99.9% of valid checkout requests must complete successfully within four seconds over a rolling 28-day window.
That objective may influence:
- timeout allocation
- retry policy
- dependency selection
- caching
- database topology
- capacity planning
- deployment strategy
- regional design
- recovery procedures
For example, the checkout deadline might be divided across dependencies:
TOTAL USER BUDGET
4 seconds
│
├── basket:
│ 300 ms
│
├── inventory:
│ 700 ms
│
├── payment:
│ 1,500 ms
│
├── order persistence:
│ 500 ms
│
└── orchestration and margin:
1,000 ms
These are not necessarily fixed timeout values.
The model reveals that every dependency cannot independently receive the full four-second deadline.
The end-to-end objective constrains the internal design.
A bfstore checkout SLO
Suppose bfstore defines the primary checkout SLO as:
Over a rolling 28-day period, at least 99.9% of eligible checkout attempts must result in a confirmed order within four seconds.
Eligible event
A checkout attempt is eligible when:
- the request is authenticated
- the basket is valid
- required request fields are present
- at least one purchasable item exists
Good event
The event is good when:
- payment reaches an accepted outcome
- inventory is reserved
- the order is durably recorded
- the response is returned within four seconds
Bad event
The event is bad when:
- an internal failure prevents completion
- the deadline is exceeded
- an accepted order is not durably recorded
- the system returns an unexpected error
Excluded event
The event may be excluded when:
- the client submits invalid input
- authentication fails correctly
- the customer cancels the request
- the item is legitimately unavailable
The eligibility rules would need careful testing.
The platform could calculate the SLI using gateway and application telemetry:
GATEWAY
request start
response status
latency
trace context
ORDER SERVICE
business outcome
order persistence
failure reason
TRACE
dependency path
The resulting SLO view might show:
target:
99.9%
current:
99.94%
remaining error budget:
40%
28-day window:
compliant
current burn rate:
0.7
This tells the team that the service remains within its objective.
The supporting telemetry explains why bad events occurred.
A bad checkout event should be traceable
An aggregate SLO number tells us that users were affected.
It does not explain the cause.
Each bad event should connect, where practical, to diagnostic evidence.
SLO BAD EVENT
│
▼
TRACE ID
│
▼
DISTRIBUTED TRACE
│
├── inventory timeout
├── payment failure
├── database delay
└── order persistence error
OpenTelemetry can help preserve:
- operation name
- service version
- environment
- trace ID
- dependency timings
- failure status
Structured logs can add business meaning:
{
"event": "checkout_failed",
"order_id": "ord_72a1",
"reason": "inventory_deadline_exceeded",
"trace_id": "7ac913..."
}
The SLO detects the broken promise.
The telemetry reconstructs the story.
SLOs need ownership
An objective should have an owner.
Ownership answers:
Who reviews the SLO?
Who responds when it burns?
Who can change the target?
Who maintains the indicator?
Who approves exclusions?
Who owns the improvement work?
For an end-to-end checkout SLO, ownership may span several teams.
The order team might own the customer journey.
The platform team might own:
- cluster availability
- telemetry pipeline
- deployment controls
The payment team might own provider integration.
JOURNEY OWNER
│
├── service teams
├── platform team
└── dependency owners
Shared contribution does not remove the need for one clear coordinating owner.
An ownerless SLO tends to remain green until the first difficult conversation, then transforms into a historical dashboard artefact.
Targets should be reviewed, not worshipped
An SLO is a decision based on current knowledge.
It may need to change.
The target may be too weak if:
- users are harmed while the objective remains green
- competitors or contracts require better service
- improved architecture makes stronger reliability affordable
The target may be too strict if:
- users receive no meaningful benefit
- the cost prevents valuable product work
- the objective was copied from another service
- the measurement does not reflect the real journey
Changing an SLO should involve evidence.
USER NEED
CURRENT PERFORMANCE
ENGINEERING COST
FAILURE CONSEQUENCES
BUSINESS PRIORITY
The target should not be lowered simply because the service missed it.
That would turn the objective into a scoreboard adjusted after every difficult match.
A missed objective should first prompt investigation into whether:
- the design is inadequate
- the indicator is wrong
- the user promise is unrealistic
- priorities need to change
Common SLO traps
Measuring what is easy
Pod readiness:
99.99%
while checkout frequently fails.
The indicator should represent the user promise.
Selecting 99.9% by habit
The target should follow user need and engineering cost.
Defining too many objectives
The team becomes unable to tell which failure matters most.
Excluding inconvenient failures
The SLO improves while the user experience does not.
Alerting on every bad event
The system produces constant noise rather than budget-based urgency.
Ignoring latency
Slow success is treated as reliable service.
Having no error-budget policy
The objective measures failure but changes no decisions.
Treating the SLO as a team performance score
Teams become motivated to manipulate the measurement instead of improving the service.
Changing the objective after every miss
The target stops functioning as a stable engineering boundary.
Forgetting the telemetry pipeline
Missing data is mistaken for successful service.
An SLO should improve decision-making.
It should not become an elaborate method for colouring the dashboard.
An SLO operating loop
A practical operating model might look like:
DEFINE USER JOURNEY
│
▼
SELECT SLI
│
▼
SET SLO
│
▼
MEASURE ERROR BUDGET
│
▼
MONITOR BURN RATE
│
├── healthy ──► continue delivery
│
├── at risk ──► reduce risk
│
└── exhausted ─► prioritise reliability
│
▼
REVIEW OUTCOME
The review should ask:
- Which events consumed the budget?
- Did alerts fire at useful times?
- Could operators diagnose the failures?
- Did the policy guide release decisions?
- Does the SLI still represent the user journey?
- Does the target still reflect product need?
- Which engineering investment would reduce future burn?
This turns the SLO into a living operating mechanism.
The questions I now ask
User
Who experiences this service?
Journey
Which action are they
depending on?
Eligibility
Which events belong
in the measurement?
Success
What makes one event good?
Indicator
Where can that experience
be measured reliably?
Target
Which level of reliability
is worth its cost?
Window
Over which period
will performance be evaluated?
Budget
How much failure
does the objective permit?
Burn
How quickly is that allowance
being consumed?
Alert
When must an operator
take action?
Policy
What changes when
the budget is at risk?
Diagnosis
Can bad events be connected
to logs, metrics and traces?
Ownership
Who maintains the promise
and coordinates recovery?
Review
Does the objective still represent
a valuable user outcome?
These questions turn reliability into something more useful than a collection of green component lights.
The mental model I am keeping
My earlier model was:
RELIABILITY
keep the system running
and respond when it breaks
The stronger model is:
USER JOURNEY
│
▼
SLI
│
▼
SLO
│
┌────────────┴────────────┐
│ │
▼ ▼
GOOD EVENTS BAD EVENTS
│ │
└────────────┬────────────┘
▼
ERROR BUDGET
│
▼
BURN RATE
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
DELIVER NORMALLY REDUCE RISK RESTORE RELIABILITY
│
▼
REVIEW AND LEARN
The user journey answers:
Which experience matters?
The SLI answers:
What level of service
did users receive?
The SLO answers:
What level should they
be able to depend on?
The error budget answers:
How much failure is acceptable
within that promise?
Burn rate answers:
How quickly is the permitted
failure being consumed?
Alerting answers:
When is the promise
in meaningful danger?
Observability answers:
Why were users affected?
The error-budget policy answers:
How should current reliability
change engineering priorities?
Ownership answers:
Who maintains and defends
the objective?
And review answers:
Does this promise still match
what users and the business need?
SLOs do not guarantee reliability.
They do something equally important.
They make the reliability decision visible.
They force a team to name the user journey, define success, choose a target and accept the cost of that promise.
They also create room for change.
A service does not need to avoid every failure forever.
It needs to keep failure within a boundary its users can tolerate.
Within that boundary, the team can release features, update dependencies and improve the platform.
When failure begins consuming the budget too quickly, the balance changes.
Reliability work moves forward because the evidence says the user promise is in danger, not because the loudest person in the meeting has discovered a particularly severe eyebrow.
An SLO is not merely a reliability percentage. It is an agreement about which user experience matters, how much failure is acceptable and when engineering priorities must change to protect the service promise.