SLOs vs SLAs: an SLO is a target for a measured level of service; an SLA is an agreement with users or customers that specifies what happens if agreed service terms are not met. The measurement underneath either is an SLI, a service level indicator. In short: SLI = measure, SLO = target, SLA = agreement and consequence. The exact SLA text controls its obligations and remedies, while an SLO can guide engineering decisions even when there is no SLA.
Google's service-level terminology makes an important qualification: “SLA” is used differently across organizations, and SLOs can be published to users. It is helpful to think of SLOs as operating targets and SLAs as commitments, but “internal versus external” is not a universal legal definition.
Define the indicator before debating its target
An SLI must say what is measured, where, and for whom. An API availability SLI might be the fraction of eligible requests that return a usable result at a defined edge. A latency SLI might be the fraction of eligible operations completed within a chosen threshold. “The servers were up” is not the same as “users could complete their task.” The Google SRE book notes that a server-side proxy may miss client-experienced latency, so the observation point matters.
Write down the numerator and denominator before choosing a percentage:
- Eligible events: which journey, route, region, customer population, and time interval count?
- Good events: what result qualifies as successful and, if applicable, fast enough?
- Bad events: which eligible events fail the test? Treat correctness failures explicitly rather than assuming a 200 status is always good.
- Exclusions: which requests are outside the contract—perhaps synthetic probes, internal traffic, malformed requests, or client cancellations—and why?
- Observation boundary: where is the event counted, and how are retries, duplicates, missing samples, and delayed data handled?
Use the same observation boundary and event population for both parts of a ratio. A client retry can create multiple backend attempts for one user action. Counting failed attempts in the numerator and user actions in the denominator produces an invalid rate. If telemetry is sampled or lost, neither a precise dashboard nor a log query automatically repairs the missing population.
An SLO adds a target and a compliance period to this definition: for example, at least 99.9% of eligible requests should be good over a stated rolling period. The number is illustrative, not a universal recommendation. Users' needs, historical performance, dependency behavior, and the cost of improving reliability should inform the target. The SRE Workbook's implementation guide recommends documenting the SLI implementation, rationale, approvers, and review date so a future reader can understand what the number means.
Calculate a request-based error budget correctly
Consider a clearly hypothetical API SLO: 99.9% of eligible requests succeed over one measurement period. If the period contains exactly 1,000,000 eligible requests, the allowed bad-request count is:
1,000,000 × (1 − 0.999) = 1,000 bad requests
At 1,000 bad requests, the measured good fraction is exactly 99.9%; at 1,001, it is below the target, assuming the population and definitions stay the same. This is a request-count budget, not an allowance of downtime minutes. Converting it to minutes would require a time- or window-based SLI and its own measurement rules. A short, high-traffic incident can consume more request budget than a longer, low-traffic one.
The error budget is the portion of eligible service that may fall below the good-event definition while the SLO is still met. It is not a planned quota of failures or permission to disregard affected users. A written policy states who responds when the budget is consumed or at risk, and how reliability work changes priority. Google’s error-budget policy guidance frames this as an agreed decision process among engineering, product, and reliability owners, not an automatic release freeze for every service.
For a latency SLO, use a similar good-event fraction: requests completed within the stated threshold divided by eligible requests. An average latency can remain low while a meaningful tail is slow; it is not equivalent to the fraction meeting the threshold. Keep the threshold, population, and boundary in the SLO text.
Specify rolling and calendar windows
A rolling window always looks backward over a fixed duration from the current evaluation time. A calendar window has fixed boundaries such as a named month. Both can be valid, but they answer slightly different questions: a calendar monthly report resets at the boundary, while a rolling-month view carries previous days into the current calculation. State timezone, start and end rules, data-delay handling, and whether the SLA uses the same window as the engineering SLO.
Do not mix windows casually. A current rolling 30-day SLO may be healthy while a contractual calendar-month condition was missed, or vice versa. Likewise, “99.9% availability” is incomplete without the event definition, period, and exclusions. If a contractual report is built from a different source than the engineering monitor, reconcile the populations before arguing about a discrepancy.
SLOs can be stricter than an SLA to create operational margin, but that is a choice, not a law. A public SLO can also communicate a service expectation without an associated contractual remedy. The agreement may include notice, support, calculation, claim, or remedy terms outside the SLO; an engineering dashboard cannot override those terms.
Alert on harmful budget consumption, not every blip
An SLO is useful only if operators can act before a material loss of service accumulates. Burn rate compares the current bad-event rate with the bad-event rate that would consume the entire budget evenly over the SLO period. For a 99.9% request SLO, the sustainable bad-event fraction is 0.1%; a burn rate of 1 means the budget would be consumed at exactly that even rate if it continued. Google’s SLO alerting guide develops multiwindow, multi-burn-rate alerts to catch fast severe failures and slower material degradation while controlling noise.
Do not copy another service's burn-rate windows or page thresholds without checking traffic and response needs. A ratio based on very few requests can spike after one failure; a missing denominator may be “no data,” not zero errors. For low-traffic services, pair the ratio with observation counts, a carefully chosen absolute-count or synthetic check, and a no-data policy. Test both firing and recovery under representative conditions. An alert should identify an owner and a runbook, not merely repeat a number already visible on a dashboard.
SLA reporting is different from paging. A breach calculation follows the agreement's defined period and exclusions, even if the operational alert fired earlier or later. Keep the raw SLI evidence and calculation version so a report can be audited.
Compare SLOs and SLAs without assuming identical scope
An SLO is an engineering and product decision about the service level to aim for. It supports prioritization, design tradeoffs, release decisions, and error-budget policy. A team can have an SLO for a background job or internal service with no customer-facing SLA. It may also publish SLOs to set expectations.
An SLA is a service agreement. Its consequences can be financial, operational, or another explicitly stated remedy; service credits are common but not universal. It may define narrower covered services, a different measurement source, claim steps, exclusions, or support terms. The contracting parties, not a generic SRE template, determine what applies. The Google SRE definition of agreements emphasizes asking what consequence follows when a commitment is missed.
Both require precise measurement. If the SLO describes server request success and the SLA describes end-user transaction completion, they are not two targets for one indicator. Document their relationship and do not imply that meeting one proves the other. A reliability review should compare user experience, SLO status, and SLA status as related but distinct facts.
Use logs to investigate, not to certify the agreement
Logs are useful for explaining which requests failed, what a deployment changed, or why a particular job was delayed. But a log query is an SLI source only if event capture is complete enough for the purpose, numerator and denominator use the same boundary, duplicates and sampling are controlled, and delivery delays are understood. Otherwise a metrics/SLO system should compute compliance while logs provide supporting evidence. See the fuller service level objective guide for defining a durable SLI and alerting best practices for testing the notification path.
Fluxtail is a paid Starter/Pro, logs-focused service. Its search and filters and Live Tail can help examine log events that were actually delivered and mapped. Its Prometheus and StatsD receivers convert accepted samples into log events; they do not make Fluxtail a native time-series, SLO, APM, or SLA-enforcement platform. Keep contractual calculations in the agreed system of record and verify any incident explanation against source evidence.
The practical distinction remains simple: define the SLI carefully, set and operate an SLO against it, and read the exact SLA to know the customer commitment and consequence. When those three layers use different populations or windows, write the difference down before treating any percentage as authoritative.