Service Level Indicators and Objectives: Measuring Reliability

"Highly reliable" is not measurable.

Teams need a precise definition of which user experience matters, how it is observed, and what target is acceptable over time.

A service level indicator measures reliability behavior; a service level objective sets the target the team intends to meet.

The gap between perfection and the target forms an error budget for managed risk.

A concrete example: API latency

An API defines a good request as:

• valid request,
• successful response,
• completed within 500 milliseconds.

Its SLI is:

good requests / eligible requests

The SLO requires 99.9 percent good requests over a rolling 30-day window.

Service level indicator

An SLI is a quantitative measurement of behavior.

Common indicators include:

• availability,
• latency,
• correctness,
• freshness,
• durability,
• and job completion before deadline.

The indicator should approximate what users experience.

Service level objective

An SLO is the desired range or target for an SLI over a window.

Example:

99.95 percent of valid checkout attempts complete successfully each calendar month.

The target is an internal operating commitment used for decisions.

Service level agreement

An SLA is a formal commitment to a customer, often with contractual consequences.

An SLO is usually an internal reliability target and may be stricter than the SLA to provide safety margin.

SLAs, SLOs, and SLIs should not be used interchangeably.

User-centered measurement

Measure at the closest practical point to the user.

A server can report 100 percent health while:

• DNS fails,
• authentication blocks users,
• a dependency returns wrong data,
• or the client cannot render.

Server-side signals remain useful for diagnosis but may not define the primary SLI.

Defining good events

Event-based SLIs classify each eligible event as good or bad.

Examples:

• request succeeded within target,
• message delivered before deadline,
• file processed correctly,
• search index reflects update within freshness target.

Define exclusions carefully so failures are not removed merely because they are inconvenient.

Valid versus invalid requests

User mistakes may be excluded from availability:

• invalid credentials,
• malformed input,
• unsupported operation.

System-caused rejection, timeout, and dependency failure normally count as bad.

Document the classification so teams cannot improve the number by relabeling errors.

Latency distributions

Average latency hides slow users.

An event-based latency SLI can count requests below a threshold. Histograms can also estimate p95 or p99.

Choose thresholds according to user and business impact, not because one round number is common.

Windows

Objectives use a time window:

• calendar month,
• rolling 28 days,
• or another defined period.

Rolling windows always reflect recent behavior. Calendar windows align with reporting but reset at boundaries.

The window affects how error budgets and alerts behave.

Error budget

For a 99.9 percent objective:

100% - 99.9% = 0.1%

of eligible events may be bad while still meeting the objective.

The budget recognizes that absolute perfection is usually prohibitively expensive.

Budget consumption

If a service uses its budget quickly, the team may:

• pause risky releases,
• prioritize reliability work,
• reduce rollout speed,
• or improve testing and safeguards.

If plenty remains, the team can take reasonable change risk.

The policy should be agreed before pressure arises.

Burn rate

Burn rate describes how quickly the error budget is being consumed.

• burn rate 1: exactly the sustainable rate,
• burn rate 10: spending budget ten times too quickly.

Fast-burn alerts detect severe incidents; slow-burn alerts detect prolonged smaller degradation.

Multi-window alerting

A robust alert may require:

• high burn over a short window,
• and elevated burn over a longer confirmation window.

This catches real impact quickly while reducing pages for one brief spike.

Different burn rates can route to page or ticket.

Choosing target strictness

Higher reliability costs more.

A 99.999 percent target allows only a few minutes of unavailability per year and may require:

• redundant regions,
• complex deployment,
• expensive capacity,
• and slower change.

Choose the target from user need and business consequence, not prestige.

Dependencies

A service objective depends on downstream services.

If three critical dependencies each target 99.9 percent independently, the combined journey may be lower. Architecture, fallback, caching, and dependency objectives need to support the end-to-end target.

Do not promise a service objective that dependency design cannot achieve.

Batch systems

Not every SLI is request based.

For a daily report:

reports completed correctly by 07:00 / reports due

Queue systems may measure age or deadline completion rather than instantaneous availability.

Data quality

A response can be fast and wrong.

Where measurable, include correctness indicators:

• valid financial totals,
• complete event processing,
• no duplicate charges,
• accurate inventory,
• or reconciled records.

Some correctness requires sampling or offline audits.

SLO ownership

Product and engineering should agree on:

• user journey,
• target,
• measurement source,
• exclusions,
• window,
• and budget policy.

One reliability team cannot define business value alone.

Review and evolution

Review SLOs when:

• user needs change,
• architecture changes,
• measurement improves,
• the target is always trivially met,
• or the target is impossible and ignored.

Do not quietly lower an objective to hide poor reliability.

Knowledge check

1. How do an SLI, SLO, and SLA differ?
2. Why should an SLI be measured close to user experience?
3. What is the error budget for a 99.9 percent objective?
4. What does a high burn rate mean?
5. Why should the strictest possible target not be chosen automatically?

The one idea to remember

SLIs turn user-relevant reliability into measurements, SLOs set explicit targets over time, and error budgets guide how much failure and change risk the team can accept. Define them honestly enough to drive decisions.