SLA vs. SLO vs. SLI: service targets, measurements, and commitments

Start with three different questions: what are we measuring, what result do we want, and what have we promised customers?

• A service level agreement (SLA) records a service commitment and the consequences of missing it. For example, an agreement might promise monthly availability of at least 99.99% and a response to support requests within 24 hours on business days.
• A service level objective (SLO) sets a target for a service indicator over a defined evaluation window. “Monthly availability of at least 99.99%” is an SLO. A team can use SLOs internally without putting them in an SLA.
• A service level indicator (SLI) measures service behavior using a defined method. “Successful requests divided by eligible requests” is one possible SLI; 99.90% is an observed value over a particular window. Compare that value with the SLO for the same window. Contractual consequences depend on the SLA's scope, calculation rules, and exclusions.

That distinction matters during an incident. A bad five-minute interval calls for investigation, but it does not, by itself, tell you whether the service has missed a monthly target or triggered a service credit.

SLA: a commitment with consequences

An SLA describes the service level a provider agrees to deliver. Availability is a common commitment. A missed commitment may result in a service credit, often applied against eligible charges, or another remedy specified in the agreement. Read the applicable terms rather than assuming that every incident creates a refund.

A useful SLA makes five things clear:

1. Scope: which services and operations the agreement covers.
2. Commitments: the service objectives that apply during the agreement.
3. Measurement: the indicators, collection method, reporting interval, and evaluation window.
4. Term: when the agreement takes effect and when it can be reviewed or renegotiated.
5. Consequences: what happens when a covered commitment is missed.

Two common problems

The first is an ambiguous definition of downtime. Does an unavailable page count? What about a page that eventually loads but is too slow to use? If the definition stops at “available,” the provider and customer may reach different conclusions from the same incident.

The second is losing sight of users. Legal, sales, procurement, and engineering teams all have legitimate concerns, but the resulting agreement still needs to describe something customers recognize as a usable service.

SLO: a service target with a time window

An SLO gives the service team a target to manage. Some targets become external commitments; others remain internal. A service does not need an SLA before its team can set SLOs.

For a request-success SLI, a 99.9% target leaves room for 0.1% of eligible requests to fail within the same evaluation window. This allowance is the error budget. It can help the team decide when reliability work needs attention. A request-based percentage cannot simply be converted into minutes of downtime: that calculation requires a time-based availability measure with a matching definition.

Define the calculation, not just the percentage

“Monthly availability of at least 99.95%” is easy to write. Deciding what goes into the calculation takes more work.

Consider a hypothetical agreement that counts downtime only when more than 10% of requests return HTTP 500 continuously for at least ten minutes. Under that definition, HTTP 502 responses, an 8% error rate, or a nine-minute interruption would not qualify. Customers could still be affected in all three cases. The example is an illustration of a narrow definition, not a statement about a particular vendor's current SLA.

Write the exact scope, thresholds, and time window in language the reader can understand. A percentage without those details is difficult to evaluate.

SLI: define the measurement before comparing results

An SLI needs a clear definition of success, a denominator, a collection point, and a policy for missing data. Only then does its observed value become useful.

A short interval below the target does not automatically mean that the monthly SLO has failed. Nor does an internal SLO miss automatically establish an SLA breach. Use the agreed evaluation window and contractual rules for each question.

Measurement also has its own failure modes. Server counters, client observations, and synthetic tests cover different parts of the user journey. Sampling, probe locations, and missing telemetry can change what a result represents. An exact-looking percentage does not remove those limits.

Does every service need an SLA?

An SLA is not a prerequisite for using SLIs and SLOs. Whether a provider offers an agreement is also a commercial decision.

For providers, procurement requirements often influence that decision. A large customer may require a formal commitment as part of purchasing the service, while a smaller self-service purchase may have different expectations. Those are purchasing patterns, not rules about which customers need reliability.

For buyers, assess the agreement alongside the service's actual operating history. A favorable credit schedule does not prevent an outage, and a status page does not establish how every customer experienced the service. Review both the documented commitment and the evidence relevant to your workload. Longer contracts and important dependencies make clarity about scope and remedies especially useful.

Five practical ways to write a better SLA

1. Start with the customer's task. Engineers may see a request as a sequence across several components; a customer wants to complete an operation. Choose a measure that reflects that outcome, then document which component failures it includes.
2. Use understandable language. State what is measured, when it is measured, and what happens when the commitment is missed. Precision does not require making the agreement unreadable.
3. Choose a few meaningful indicators. The monitoring system can collect far more metrics than belong in a service agreement. Include the ones that describe the experience being promised.
4. Leave room around the external SLO. For example, an internal target of 99.95% and an external commitment of 99.9% can provide a buffer when their measurement rules and windows match. The numbers are illustrative; choose targets the service can support and customers need.
5. Define exclusions explicitly. If a support process pauses while waiting for information from a customer, specify whether and how that time affects the response or resolution commitment. Do not leave the counting rules to be decided after an incident.

Use observability to support the commitment

A service promise is easier to evaluate when the team can explain the measurements behind it. Guance synthetic monitoring can collect availability data from selected probe locations at configured intervals. Monitors and event timelines can help the team investigate failures and its response.

Those observations can support SLO evaluation, but they do not automatically become contractually accepted evidence of SLA compliance. Agree on measurement scope and retention first. The Guance SLO management guide explains the product configuration; the synthetic monitoring documentation describes the probing side of the workflow.

Common questions

Should we define an SLO or an SLA first?

Defining and validating the SLI and SLO before making an external commitment is a useful way to reduce risk. It is not a mandatory sequence. SLOs remain useful even when no SLA exists.

Must the internal and external targets be different?

No. They can be the same or different. A stricter internal target can provide headroom, but compare percentages only when the measurement method and evaluation window match.

Which tool makes an SLI valid?

The tool name is not the deciding factor. Server-side counters, client observations, and synthetic probes can each be appropriate. Choose a method that measures the intended experience, understand its coverage, and document the method in the agreement where it is used.

What if a customer requests a remedy that the SLA does not mention?

Review the main contract, other applicable terms, and the SLA's scope with the commercial and legal teams. The absence of a remedy from the SLA alone does not establish every obligation under the wider agreement.

Sources

Technical definitions and product documentation checked on October 27, 2026. Numeric targets are examples, not measured service results or vendor commitments.

• Google SRE: service level indicators, objectives, and agreements
• Google Cloud: service monitoring and error budgets
• Guance: manage SLOs
• Guance: synthetic monitoring