SLA (Service Level Agreement)

A service level agreement (SLA) is an agreement with users that includes consequences for meeting or missing a service commitment. Google’s SRE book allows explicit or implicit agreements and consequences beyond financial credits. The distinction is the agreed obligation: lost revenue, reputational damage, or an internal incident response can occur without an SLA.

How it relates to SLIs and SLOs

An SLI defines a measurement, an SLO sets a target, and an SLA states consequences attached to an agreed service level, such as a credit or a right to terminate. Internal and contractual measures can use different populations, windows, or exclusions; inspect each definition before comparing their values.

Providers can choose a tighter internal SLO to leave operating margin before the SLA target is missed. If both use the same event population, success rule, boundary, exclusions, and calendar month, an internal target of 99.9 percent is tighter than a contractual 99.5 percent. A reading of 99.6 percent misses the former and meets the latter. With identical definitions, equal targets leave no numerical gap. Different definitions require separate calculations, and the percentages alone cannot establish how much warning time the team has.

The two are also written by different people. The SRE book notes that site reliability engineers do not typically construct SLAs, because SLAs are closely tied to business and product decisions. What engineering contributes is an indicator precise enough that both parties compute the same number — which prevents a dispute over whether the agreement was breached at all.

The clauses that decide what it promises

The headline percentage is the least informative part of an SLA. What it actually guarantees is set by the surrounding clauses, and a public cloud SLA — Amazon’s compute SLA is used here as an example — shows each of them clearly.

• The definition of failure. In the Instance-Level Amazon Compute SLA, unavailability means a single EC2 instance has no external connectivity. The Region-Level SLA has a different condition: concurrent loss of external connectivity for all running instances across the required AZ deployment. A slow or partially degraded application need not meet either definition.
• The measurement period. Downtime is summed over the month, so one long outage and many short ones with the same total count the same, and an incident that spans a month boundary is split between two periods.
• The exclusions. Typical ones cover factors outside the provider’s reasonable control, the customer’s own actions, and the customer’s equipment or software.
• The remedy. Usually service credits against future bills — and in Amazon’s SLA, stated to be the sole and exclusive remedy for unavailability or other failure to provide the service.
• The claim process. Credits may not be issued automatically. Amazon requires the customer to submit a claim, with supporting details, by the end of the second billing cycle after the incident.

These clauses determine the remedy, not the mechanism that restores service. AWS service-credit claims require evidence and timely submission. The same SLA separately provides an automatic billing exemption for a single EC2 instance unavailable for more than six minutes of a clockhour, without a credit request. Distinguish such automatic provisions from claim-based credits, and assess the business impact independently of the compensation.

What you can promise depends on what you depend on

A service commitment needs an architecture capable of supporting it. In a simplified serial path that requires three components to work, independent component availabilities of 99.99 percent give a combined availability of about 99.97 percent (0.9999 × 0.9999 × 0.9999). Those inputs must describe compatible actual availability probabilities, not merely the headline percentages in three vendor contracts. Contractual targets, exclusions and measurement windows are not failure probabilities. Shared failure causes also invalidate the independence assumption. Evaluate redundancy, fallback, caching and the actual user-visible failure path before setting a commitment; multiplying SLA percentages alone cannot establish what the service will deliver.

Internal SLAs and other uses

Teams inside an organization can also make service agreements. An escalation, chargeback, or priority change can be an agreed consequence when it belongs to the commitment between provider and consumer. A team’s own response to an internal SLO miss is not automatically an SLA. Document what the parties have agreed rather than deciding from the existence of any operational consequence.

The same contract form is common outside technology. Supply chain agreements define service levels for on-time delivery, order fill rate, and defect rates, with remedies such as discounts or escalation. The structure — a measured indicator, a target, a defined period, exclusions, and a consequence — is the same, which is why the clauses above are worth checking in any SLA, whatever it covers.

References

• Google, Site Reliability Engineering, Service Level Objectives
• AWS, Amazon Compute Service Level Agreement