SLAs in SaaS agreements – availability, response time, RTO, RPO, and service credits
An SLA makes the SaaS provider's service level measurable. It should define what availability means, how it is calculated, how incidents are prioritized, what response times apply, which recovery targets are relevant, and what the customer receives if the service level is not met.
What is an SLA in a SaaS agreement?
SLA stands for Service Level Agreement and is often an appendix to the main agreement. The main agreement describes the commercial relationship, while the SLA specifies the measurable quality levels of the ongoing service.
A good SLA should be usable both during normal operations and when something goes wrong. If the parties only start discussing what "critical disruption" or "99.9 percent availability" means when an incident occurs, the agreement is too vague.
See also the main guide on what a SaaS agreement should contain.
Availability – the percentage is just the beginning
An availability level, for example 99.9 percent, says little without measurement rules. Therefore, specify:
- which service or components are covered,
- measurement period, for example calendar month,
- which data source is used,
- when downtime begins and ends,
- if planned maintenance is excluded,
- how customer-caused errors or force majeure are handled,
- if performance degradation can count as unavailability.
The difference between 99.9 and 99.99 percent can be commercially significant. The requirement should therefore be based on how business-critical the service is and what the provider's technical architecture can actually deliver.
| Measurement point | Question to answer |
|---|---|
| Availability | What percentage level, period, and components apply? |
| P1/P2/P3 | How are critical, high, and normal incidents defined? |
| Response time | When should the provider have initiated qualified handling? |
| Recovery | Are there targets for service and data recovery? |
| Communication | How often should the customer receive status updates? |
| Penalty | When do service credits or other rights apply? |
Incident classes and response time
Incident classification should be based on impact, not just the technical error type. An error may be technically limited but business-critical if, for example, it blocks payments or access to a central process.
For each priority level, the SLA can specify the initial response time, target time for a workaround or recovery, update frequency, and escalation level. Be careful with the difference between response time and resolution time. A response within 30 minutes does not automatically mean the error should be resolved within 30 minutes.
Support windows must match operations
A P1 response time of 30 minutes is useless for a business that operates 24/7 if the provider's support is only open weekdays 9 AM–5 PM. Specify which levels apply outside of regular support hours and how critical incidents are reported.
RTO and RPO – two different recovery targets
RTO (Recovery Time Objective) is used as a target for how quickly a service or process needs to be restored after an outage. RPO (Recovery Point Objective) is used as a target for how much data loss backward in time can be tolerated in a recovery situation.
They should not be selected in isolation in the IT agreement. A BIA (Business Impact Analysis) can show how long the business can actually withstand an outage and what data loss is acceptable. Read the guide on Business Impact Analysis and the practical BIA example.
Also check what the provider means by their values. Is the RTO a goal, a guarantee, or merely an internal design principle? Does the RPO apply to all data types? How often is the recovery tested?
Service credits – compensation or sole remedy?
Service credits can create an automatic financial incentive when the service level is missed. A tiered model can, for example, provide a larger credit the further the service falls below the target level.
However, check if the agreement states that service credit is the customer's sole remedy. In the event of serious or recurring deficiencies, the customer may need other rights, such as the right to an action plan, special escalation, or termination. Coordinate the SLA with the main agreement's limitation of liability and termination rules.
Planned maintenance and other exceptions
The provider normally needs to be able to maintain the service, but too broad an exception can make the availability target misleading. Regulate how far in advance maintenance must be announced, which time windows may be used, and if emergency security maintenance is handled differently.
Also be cautious with exceptions for third-party services. If the provider has chosen a critical cloud or infrastructure provider, the agreement should clarify how that dependency affects the SLA and liability.
Checklist for a useful SLA
- Is the measured service clearly defined?
- Is there an unambiguous formula for availability?
- Is planned maintenance clearly limited?
- Are incident levels linked to business impact?
- Does the agreement distinguish between response, workaround, and resolution?
- Does support function during your critical operating hours?
- Are RTO/RPO linked to actual continuity needs?
- Are there requirements for status updates during P1 incidents?
- Are service credits and other remedies clear?
- Is there a right to act in case of repeated SLA breaches?
Do you need a main agreement and SLA in the same structure?
Mallbutiken’s SaaS agreement includes a main agreement and six appendices for, among other things, service specification, SLA, DPA/GDPR, security, exit, and price. Word and PDF. Price in store: 149 SEK.
View the SaaS agreementFrequently asked questions
Is 99.9 percent always a good SLA?
No. The right level depends on the criticality of the service, measurement method, exceptions, and the cost of higher redundancy. The percentage must be placed in context.
Is RTO the same thing as SLA availability?
No. Availability normally measures uptime over a period. RTO is about the goal for recovery after an outage.
Should service credit be the only remedy?
This is a matter of contract, but the customer should consciously assess whether credit alone is sufficient in the event of serious or repeated breaches.
Related guidance
Read the SaaS agreement guide, NIS2 and supplier security, and the continuity plan guide.
Sources and further reading
The guide provides general information. SLA levels should be adapted to the service's architecture, business criticality, and other contractual terms.
