SLA — what it is and what to check in an SLA with a cloud provider

SLA — what does it mean, and why does it show up in every contract with a cloud provider? The term stands for service level agreement: a document in which a provider writes down how well its service is supposed to work, and what happens if it doesn't keep its word. In cloud and SaaS services, this usually comes down to one number — a monthly uptime percentage, say 99.9%. That number sounds like a promise that the service will almost never go down. In practice it means something far more modest.

This article covers the SLAs of cloud providers, SaaS software and IT services your company relies on: e-mail, office suites, cloud servers. We show how much downtime typical SLA levels actually allow, how AWS, Microsoft and Google's agreements compare, how SLA differs from SLO, what RPO and RTO mean, and how an SLA sits against EU contract law. At the end you'll find a list of 10 things to check before you sign. If you're looking for a service contract for a company website rather than a cloud service, that's a separate topic covered in our article on website maintenance.

SLA meaning — the definition, and what an SLA is not

The most precise definition you can read for free comes from the ISO/IEC 17788:2014 standard, published in parallel by the ITU as Recommendation Y.3500. In point 3.1.7 it adopts a definition from the service-management standard ISO/IEC 20000-1 (ITU-T Y.3500, 08/2014):

> "service level agreement (SLA): Documented agreement between the service provider and customer that identifies services and service targets."

In other words: a service level agreement is a documented agreement between a provider and a customer that identifies the services and their targets. Two notes attached to this definition matter just as much in practice. First: an SLA can also apply between a provider and its subcontractor, or an internal department. Second: an SLA "can be included in a contract or another type of documented agreement". In the cloud it's usually a separate document that the terms of service refer to, and that the provider can update.

Microsoft's own guide to reading an SLA puts it more practically: an SLA is "a contractual commitment between a service provider and a customer, with defined consequences for unmet targets", and at the same time "a set of conditional commitments" (Microsoft Learn, 31.03.2026). The word "conditional" is the key to the whole topic.

What an SLA is not. An SLA is not a guarantee that a service won't fail. The provider doesn't promise an outage won't happen — it promises what it will do if an outage exceeds an agreed limit. In the cloud, that consequence is almost always a service credit: a discount on a future bill, not a payout. Microsoft states this outright: "Credits don't cover lost revenue, customer attrition, or reputational damage", and providers "don't usually apply them automatically".

How much downtime fits in 99.9% — uptime in minutes

Uptime in an SLA is the percentage of time a service is up, measured over a given period. The allowed downtime follows a simple formula:

allowed downtime = (1 − SLA / 100) × minutes in the period

A 30-day month has 43,200 minutes, a 365-day year 525,600 minutes. For 99.9% in a month, that comes to 0.001 × 43,200 = 43.2 minutes. The table below shows typical levels (our own calculations):

Two things follow from this table. First, the gap between "two nines" and "four nines" is the gap between over seven hours and four minutes a month — these are not cosmetic improvements. Second, providers measure uptime over a month, not in real time. Microsoft Learn: "SLAs usually measure uptime over a billing period, not in real time". The annual 8.76-hour figure for 99.9% is therefore just an illustrative conversion. A provider can stay within its SLA every month, and a single 40-minute outage at the wrong moment — say, on month-end closing day — can still stop your business cold.

The table also doesn't show what the provider counts as downtime — and exclusions and the definition of "unavailability" can make the real-world outage longer than the one in the SLA statistics.

How the big providers' SLAs actually read

Below are three documents in the versions we read: AWS and Google on 30 September 2026, Microsoft's October 2026 edition on 2 October 2026.

AWS: Amazon Compute SLA (EC2)

The document for EC2 virtual servers is dated "Last Updated: May 25, 2022" (AWS). It contains two commitment levels:

• 99.99% at the region level — applies to instances deployed across at least two availability zones;
• 99.5% at the single-instance level.

Compensation is a percentage of fees: for the region, 10% below 99.99% but at least 99.0%; 30% below 99.0% but at least 95.0%; 100% below 95.0%. For a single instance, the first threshold is the range from 99.0% up to but below 99.5%, with the other tiers the same. AWS also doesn't charge for a single instance that's unavailable for more than six minutes in a given clock hour — the only part of this that applies automatically.

Everything else you have to claim yourself. A credit is granted after a request filed in the AWS Support Center, which must arrive by the end of the second billing cycle after the incident. The credit is only issued if it exceeds one dollar, and it can only be applied to future payments: "Service Credits will not entitle you to any refund". The SLA excludes, among other things, unavailability caused by force majeure, internet problems outside the boundary of AWS's EC2 infrastructure, and the customer's own acts, omissions, hardware or software. The most important sentence comes at the end: the SLA sets out "your sole and exclusive remedies" for unavailability.

Microsoft: Service Level Agreement for Online Services

Microsoft publishes a consolidated document covering its online services: the "Service Level Agreement for Microsoft Online Services, October 1, 2026" (Microsoft, SLA for Online Services). Its sole-remedy clause reads: "Service Credits are your sole and exclusive remedy for any performance or availability issues for any Service under the Agreement and this SLA. You may not unilaterally offset your Applicable Service Fees for any performance or availability issues."

The document adds that credits will "not, under any circumstance, exceed your monthly service fees for that Service", and will not be awarded to compensate for other losses, "including but not limited to lost revenue, operational costs, or any indirect losses experienced by you or the end-users".

The exclusion for scheduled maintenance matters too. "Scheduled Downtime" is downtime related to network, hardware or service maintenance or upgrades, about which the document says: "We will publish notice or notify you at least five (5) days prior to the commencement of such Downtime." That downtime doesn't count toward the SLA's downtime. For some services Microsoft drops this exclusion: for Exchange Online, the document states that "there is no Scheduled Downtime for this service".

Levels for the services most companies rely on: Exchange Online and Teams — 99.9%, with a 25% credit below 99.9%, 50% below 99% and 100% below 95%. For Exchange, downtime means a period in which users can't send or receive e-mail via Outlook Web Access. The claim deadline for Azure is 60 days from the incident; for other services, the end of the billing period following the month of the incident; processing typically takes up to 45 days. Preview versions and free plans aren't covered by the SLA.

Google Workspace SLA

Google's document is dated "Last modified: August 31, 2026" (Google Workspace SLA). The commitment: monthly availability "at least 99.9% in any calendar month".

Google calculates compensation differently from AWS and Microsoft — in days of service: 3 days below 99.9% (but at least 99.0%), 7 days below 99.0% (at least 95.0%) and 15 days below 95.0%. The total credit in a month can't exceed 15 days. Customers billed offline by invoice get the days added at the end of the contract period; customers paying online get a monetary credit equal to those days on a future invoice.

Downtime is a period in which the service's web interface has more than five percent user errors. A claim has to be filed within 30 days of the moment the customer became eligible for the credit — after that, the right lapses. Here too, the SLA is the customer's "sole and exclusive remedy". One detail: the document contains no scheduled-maintenance exclusion at all.

What all three documents share. Compensation takes the form of a credit against future service, you have to claim it within a set deadline, it has an upper limit, and it's the only remedy the agreement provides. A credit worth even 100% of a month's e-mail fee is usually a fraction of what a day without e-mail actually costs your business.

SLA vs SLO vs SLI — three terms that are easy to mix up

Alongside SLA, two other abbreviations come up in reliability conversations. The most widely cited definitions come from Google's Site Reliability Engineering book, in its chapter on service level objectives (Google SRE Book):

• SLI — "An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided." In practice: the share of successful requests, or response time, for example.
• SLO — "An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI."
• SLA — "SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain."

The authors offer a simple test: ask "what happens if the SLOs aren't met?". If there's no clear consequence, you're almost certainly looking at an SLO, not an SLA.

For a customer, this distinction has practical weight: a statement like "we aim for 99.95% availability" describes an SLO — a target. What actually binds the provider is the document that ties the number to a consequence.

RPO and RTO — how much data and how much time you can lose

An SLA talks about availability: how long a service can be down. It says nothing about how much data you'll lose after a serious outage, or how fast you'll be back up after a disaster. Two other terms cover that, best described in NIST SP 800-34 Rev. 1, the publication on IT contingency planning, in its section on business impact analysis (NIST SP 800-34 Rev. 1, May 2010, p. 17):

> "Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD."

RTO (recovery time objective) is the maximum time a system resource can stay unavailable before the impact on other resources, supported business processes and the MTD — the maximum tolerable downtime of a business process — becomes unacceptable.

> "Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage."

RPO (recovery point objective) is the point in time before a disruption or outage to which business process data can be restored, based on the most recent backup. NIST adds that RPO expresses how much data loss a business process can tolerate.

In short: RTO answers "how long", RPO answers "from what point". If a backup runs once a day, RPO is, in the worst case, 24 hours: anything entered since the last backup has to be re-entered by hand, or is simply lost. None of the three SLAs described above contains RPO or RTO commitments for customer data — they talk about service availability, not about recovering your data. Those parameters have to be set separately, or guaranteed yourself. How to plan backups and recovery for a website is covered in our article on backup and recovery.

SLAs and Polish law

An SLA with a foreign provider is governed by the law named in the main contract, but the reference point for a Polish company is the Civil Code (Kodeks cywilny). We cite the consolidated text (Dz.U. 2026 item 795); the translations are ours, and this section is not legal advice. There is no single, harmonised EU rule on contractual liability, limitation clauses or penalty clauses between businesses.

Art. 471 — the general rule. A debtor must compensate the damage caused by non-performance or improper performance of an obligation, unless the non-performance or improper performance results from circumstances for which the debtor is not liable. Without any SLA, a provider would therefore be liable on general terms for damage caused by a defective service.

Art. 473 — limits on contractual changes to liability. The parties may modify the scope of liability by contract, but § 2 sets a hard limit: a clause stating that the debtor will not be liable for damage it may cause the creditor intentionally is void. Clauses such as "a credit is the sole remedy" limit liability, and Art. 473 § 2 shows that under Polish law such limits are not unlimited.

**Arts. 483 and 484 — contractual penalty (kara umowna).** Under Art. 483 § 1, a contract may stipulate that damage resulting from non-performance or improper performance of a non-monetary obligation will be made good by payment of a specified sum (the contractual penalty). Art. 484 § 1 adds that the penalty is due regardless of the amount of the damage actually suffered, and that a claim for damages exceeding it is not admissible unless the parties agreed otherwise. Under § 2, the debtor may ask for the penalty to be reduced if the obligation has been performed in a substantial part or the penalty is grossly excessive.

Is a service credit a contractual penalty? We stop here deliberately. A credit looks like a contractual penalty under Art. 483 — a pre-set amount for defective performance — but it takes the form of a discount on future fees rather than payment of a "specified sum". We haven't found a source that settles this classification either way. If a meaningful share of your company's revenue depends on a service's availability, this is exactly the question to put to a lawyer before you sign — together with the question of governing law and jurisdiction.

DORA — financial entities only. Regulation (EU) 2022/2554, applicable from 17 January 2025 (Art. 64), states in Art. 30(1) that a financial entity's contract with an ICT service provider "shall include the service level agreements", and lists among its minimum elements "service level descriptions, including updates and revisions thereof" (Art. 30(2)(e)). For critical or important functions, full descriptions are required with "precise quantitative and qualitative performance targets" (Art. 30(3)(a)), along with exit strategies (DORA, EUR-Lex). DORA applies only to financial entities and their ICT contracts — it isn't a general requirement for every SaaS agreement. For other companies, though, it's a useful checklist.

NIS2 — indirectly. Directive (EU) 2022/2555 doesn't name SLAs directly, but Art. 21(2) requires entities in scope to take measures covering, among others, "business continuity, such as backup management and disaster recovery, and crisis management" (point (c)) and "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" (point (d)) (NIS2, EUR-Lex). As of July 2026, all but four member states had transposed it — Spain, France, Ireland and the Netherlands were referred to the Court of Justice of the EU. In Poland the Directive is implemented by the act of 23 January 2026 amending the Act on the National Cybersecurity System (ustawa o krajowym systemie cyberbezpieczeństwa, Dz.U. 2026 item 252), in force since 3 April 2026. We haven't verified whether it contains specific requirements for contracts with suppliers.

10 things to check in an SLA before you sign

Everything above comes down to a checklist. It applies to any SLA — with a large cloud provider, a smaller SaaS company, or an IT services provider:

1. Exclusions. What doesn't count as downtime: force majeure, internet problems, the customer's own actions, account suspension. The wider the list, the less the nines are worth.
2. Scheduled maintenance. Is it excluded from the availability calculation, how much notice does the provider give (at least 5 days with Microsoft) and is there a cap on its length? Some providers don't exclude it at all.
3. How availability is measured. What exactly counts as "unavailable": no server response, an error rate (above 5% with Google), the inability to send e-mail? Over what period is the percentage calculated — a calendar month or a billing period?
4. Claim deadline and format. AWS: by the end of the second billing cycle. Google: 30 days. Microsoft, for Azure: 60 days. Credits usually aren't applied automatically — someone at your company has to track and file claims.
5. Compensation cap. Usually 100% of a month's service fee (Microsoft) or 15 days of service (Google) — regardless of how long the outage actually lasted.
6. The sole-remedy clause. Does the SLA state that a credit is the customer's only entitlement? All three providers covered here phrase it that way, which means an SLA doesn't give you a claim for lost revenue.
7. Support response time. Availability is one thing; how fast someone responds to an outage report is another. Check whether response times are actually in the agreement, or only on a support-plan pricing page.
8. RPO and RTO. Does the provider state from what point, and in how much time, it will restore your data at all? If not, assume you have to guarantee that yourself.
9. Availability reports. Does the provider publish a history of availability and incidents, or do you have to measure it yourself just to know you're entitled to a credit?
10. Changing provider. What happens to your data after termination, and in what format and timeframe you'll get it back. More on exit strategy and the obligations providers have under the Data Act is in our article on cloud data security.

SLAs for a small business — what you can negotiate, and what you have to cover yourself

The honest answer is: with a large cloud provider, a small business usually won't negotiate anything. AWS, Microsoft and Google's SLAs are standard documents, accepted together with the terms of service, and changes are published by the provider. Negotiation is realistic mainly with smaller SaaS vendors, local IT companies and custom-software contractors. There it's worth discussing response times, an out-of-hours incident channel, backup parameters, and the format you'll get your data in if you part ways. The choice between a ready-made service and your own system — and the resulting difference in responsibility — is covered in our article on on-premise.

Since a credit won't cover your losses, real protection comes from what the company does on its own. Three things matter most:

• Your own monitoring. If you don't know when a service was down, you won't file a claim in time, and you won't be able to check the provider's own report. Simple external uptime monitoring shows downtime from your perspective, not the provider's statistics. How this works for websites is covered in our article on website monitoring.
• Your own backups. An SLA covers service availability, not your data. A backup kept somewhere other than the service itself is the only way RPO depends on you rather than on the provider — see our article on website backup.
• A plan B for a few hours. For processes that can't stop — order handling, customer contact, payments — it's worth knowing in advance what you'll do if a service is down for half a day: an alternative contact channel, an off-system order list, someone responsible for communicating with customers.

If the SLA you're actually interested in is for a company website rather than a cloud service, you're really talking about a maintenance contract: response time, updates, backups and monitoring. That topic is covered in our article on website maintenance, and the maintenance cost calculator gives a rough idea of what that kind of care costs.

What's next

What cloud computing actually is, and how the IaaS, PaaS and SaaS models differ — and so which layers are covered by a provider's SLA — is explained in our article on cloud computing. More on the SaaS model itself is in our guide to SaaS. If you're choosing a provider for a critical system and want to go through the contract with someone who understands the technical side, see our technology consulting.