What is a service level agreement?
A service level agreement, or SLA, sets expectations for a service and what follows when the stated commitment is missed. It can address availability, support, or other defined behavior. Its useful meaning depends on scope, measurement, responsibilities, and consequences, not just a percentage in a sales page.
Google's SRE guidance distinguishes service level indicators, objectives, and agreements. An indicator measures behavior, an objective names a target, and an agreement connects commitments to consequences. Keeping those concepts separate helps a SaaS team understand what it is actually promising.
This guide provides educational measurement examples and a planning worksheet. It does not offer a ready-to-sign contract or define obligations for your business. The fictional examples describe no current ShowMeYourSaaS service commitment.
Download the worksheet and availability lab
The text worksheet helps record the covered operation, measurement window, eligible population, data source, target, exclusions, and review questions. It also includes the original worked examples. The JavaScript module calculates time-based and request-based availability from explicit inputs.
Run node saas-availability-lab.mjs with Node.js 22 or later to print the examples. It makes no network requests, writes no files, and monitors no service. Read and adapt the exported functions if you want to investigate a local dataset.
The calculator cannot decide which minutes or requests a real agreement covers. Resolve that definition before entering counts. A mathematically correct percentage can answer the wrong question when its denominator includes excluded operations or misses eligible failures.
Separate SLI, SLO, and SLA in a SaaS example
Suppose a fictional export API measures the proportion of eligible requests that finish successfully under a defined rule. That measured proportion is its SLI. A target of at least 99.9% during a stated period is an SLO in this example.
An SLA would additionally define the service commitment and its consequences, along with the applicable scope and terms. An internal engineering target does not become a customer agreement merely because the dashboard uses the same percentage.
Support response time is another possible measurement, but it is different from resolution time and from API availability. A team can acknowledge a ticket while the underlying service remains impaired. Name the event that starts and stops each timer.
| Term | Example | Question to resolve |
|---|---|---|
| SLI | Successful eligible export requests / eligible export requests | Which outcomes and requests count? |
| SLO | At least 99.9% in the stated window | Which window and aggregation apply? |
| SLA | Defined commitment with specified consequences | What actual terms govern the commitment? |
| Support target | Time to first qualifying response | What starts, pauses, and ends the timer? |
Calculate a time-based availability example
For a deliberately simplified time-based model, take a 30-day window with 43,200 eligible minutes. If 60 of those minutes are classified as unavailable, availability is (43,200 − 60) ÷ 43,200 × 100, or approximately 99.8611%.
Under that model, a 99.9% target allows 43.2 unavailable minutes. Sixty minutes exceeds that allowance by 16.8 minutes. The lab reproduces the calculation and treats an observation exactly at the allowance as meeting the numerical target within a tiny floating-point tolerance.
A 31-day window has 44,640 minutes, so the same target corresponds to 44.64 unavailable minutes. Do not publish a fixed minutes-of-downtime claim without its period and counting definition. The example's allowance is arithmetic for this model, not a statement that a customer must accept an outage.
Define whether overlapping incident intervals are merged before counting unavailable time. Adding two incident durations that overlap can double-count the same minute. The lab accepts an already classified total; it does not reconcile incident intervals for you.
Know when a request-based measure answers a different question
A request-based example has 1,000,000 eligible requests and 500 classified failures. Its success fraction is 999,500 ÷ 1,000,000, or 99.95%. That is not automatically the same as the fraction of time the service was usable.
Quiet periods, traffic mix, retries, and partial degradation can affect the difference. Define the measured operation and the way failures are classified before comparing services. A request succeeding eventually may still fail a latency-based objective.
If there are no eligible requests in the window, the lab returns an unavailable percentage and an unknown target result. It does not turn a missing observation into 100% success. The appropriate treatment in a real report depends on its documented measurement policy.
Read scope and consequences in the actual agreement
A real SLA can define covered products or operations, calculation rules, exclusions, claim procedures, and remedies. Atlassian's published SLA is a concrete example of those distinctions. Its terms apply to its eligible services; they are not defaults to copy into another SaaS.
Separate the calculation you can reproduce from the agreement's actual determination process. Your local logs may help diagnose an incident while the governing terms specify another data source or method for a service-credit assessment.
Before making a customer-facing commitment, confirm that the service, monitoring, support coverage, and review process can support it. Use qualified review for the actual contract. A download or a numerical result cannot settle legal meaning or automatically establish compensation.
Connect the measurement to operations
Name the owner of the measurement, the authoritative data source, and how gaps or classification changes are reviewed. Keep an incident record so a later analyst can explain why a period was counted as unavailable or why a request was eligible.
The incident response plan covers coordination and recovery when a serious event occurs. Customer success concerns customers achieving useful outcomes. Neither can be reduced to an uptime percentage.
A rate limit may reject an operation according to a service policy. Whether that response counts in an availability measure is part of the measurement contract; do not silently include or exclude it to improve the reported result.
Check the inputs and report the limits
The local lab rejects missing, nonnumeric, non-finite, negative, or impossible counts. Time windows must be positive, downtime cannot exceed the window, and request counts must be safe integers with failures no greater than requests. Target percentages must be between zero and 100.
We checked the 30-day example, 31-day allowance, exact target boundary, zero downtime, full downtime, request-based result, zero eligible requests, and invalid inputs. Those checks establish the arithmetic of the demonstration, not the availability of a real service.
Primary sources and original materials checked October 28, 2026. Revisit actual provider terms and measurement definitions before relying on a customer-facing service commitment.