A SaaS SLA promising 99.9% availability: what does it actually protect?

The system is unavailable for 43 minutes. Orders stop, staff switch to a manual process, and the vendor says the monthly SLA has not been breached. The customer finds a 99.9% availability promise but no clear answer about when downtime started, whether one failed module counts, or what remedy follows.

A SaaS service level agreement is useful when its percentage can be turned into a measurement, a response and a specific consequence. This article examines those contractual choices for SaaS businesses and customers. Infrastructure vendors’ published SLAs are examples of how definitions work, not terms that automatically govern your application.

What you will learn

In brief

• 99.9% availability permits 43 minutes and 12 seconds of downtime in a 30-day month.
• The result depends on the definition, monitoring evidence and exclusions.
• A working login screen is not enough if the customer cannot complete a critical transaction.
• A service credit may settle an ordinary outage quickly, but be much smaller than its business cost.
• Repeated failures, lost data and security incidents need more than another discount.

What is an SLA?

A service level agreement specifies measurable service levels and the consequences of failing to meet them. It may be an appendix or part of the main agreement. SaaS service levels can cover availability, support response, incident resolution, backups, performance and recovery.

Related terms describe different things:

• SLO: a service level objective, such as monthly availability of 99.9%.
• KPI: an indicator used to observe quality, which may not trigger a contractual remedy.
• Service credit: a reduction in a future charge or an amount credited to a later bill.
• Contractual penalty: a predetermined payment for a defined contractual breach. In Polish law, kara umowna is a specific legal mechanism whose availability and consequences should be assessed under the governing rules, rather than treated as another name for every service credit.

Read the operative clauses. A heading marked “SLA” does not show what is measured or which rights the customer has.

How much downtime does 99.9% permit?

A 30-day month has 43,200 minutes. At 99.9%, permitted downtime is 0.1% of that period: 43 minutes and 12 seconds.

Availability	Permitted downtime in a 30-day month
99%	7 hours 12 minutes
99.5%	3 hours 36 minutes
99.9%	43 minutes 12 seconds
99.95%	21 minutes 36 seconds
99.99%	About 4 minutes 19 seconds

The calculation is:

Availability = (total measured time minus downtime) / total measured time × 100%.

The contract can change the outcome by excluding maintenance, ignoring interruptions shorter than a minute, measuring regions separately or excluding a third-party service failure. Two products with a 99.9% promise may offer very different protection.

What needs to be available?

Measure the function the customer needs to perform. A responding server does not show that an order can be saved, a document sent or a report retrieved.

An SLA might cover the whole product, a customer portal, API, specified critical functions, individual modules, a region or an environment. Different functions can have different targets. The customer should know which target applies to the process supporting its sales or operations.

Measure the business process the customer relies on, rather than whichever infrastructure component is easiest to monitor.

When does an outage start and end?

Possible starting points include the vendor’s monitoring alert, the customer’s first report or the time later established from logs. Counting only from the support ticket can lose a substantial part of the actual interruption.

Agree:

• Data sources and monitoring frequency.
• Any minimum outage duration and aggregation of short interruptions.
• The time zone and measurement period.
• The conditions showing that service has been restored.
• How differences between customer and vendor evidence will be resolved.

Combining automatic monitoring with the customer’s ability to show an earlier start avoids making one party the sole judge of its own performance.

The AWS Compute SLA distinguishes single-instance commitments from deployments across multiple availability zones. The Google Compute Engine SLA also distinguishes configurations. These are infrastructure commitments. Translate their assumptions into your application’s architecture before using them in a SaaS agreement.

Is a very slow service still available?

A service can respond while being too slow to complete a useful task. If performance matters, measure it separately: API response time, report generation time, error rate or synchronisation delay.

A p95 target means 95% of the measured responses must fall within the agreed time. The remaining 5% may take longer. This can be more informative than an average that a few very fast responses improve.

Specify the operation, measurement conditions and threshold in terms the business team can check. A technical label without its test conditions can create another dispute.

How should planned maintenance work?

Excluding scheduled maintenance can be reasonable when the customer knows the rules, receives notice and can plan around a defined window. Agree its frequency, duration, timing, notice period and the maximum total time excluded from measurement.

Emergency security work needs its own treatment. A critical patch may not allow the usual notice period, but that does not justify an unlimited exclusion for everything the vendor announces as maintenance.

Which exclusions are reasonable?

Common exclusions concern customer misuse, infrastructure controlled solely by the customer, notified maintenance, force majeure, permitted suspension, test features, exceeded limits and Internet failures outside the vendor’s responsibility.

The important question is how far the exclusion reaches. Excluding every third-party problem transfers much of the supply-chain risk to the customer, even where the SaaS vendor chose the architecture and could have limited the consequences with redundancy or recovery arrangements.

Distinguish an event genuinely outside the vendor’s control from consequences it could reasonably have reduced. The contractual allocation should reflect the product and the service being sold.

How do service credits work?

A service credit provides an agreed financial consequence without requiring a detailed calculation of damage for each ordinary outage. An illustrative schedule might be:

• At least 99.9%: no credit.
• At least 99.0% but below 99.9%: 10% of the monthly fee.
• At least 95.0% but below 99.0%: 25%.
• Below 95.0%: 50%.

This is an example for negotiation, not a statutory entitlement. Specify which fee forms the base: one failed module, the affected service or the entire subscription.

Also check whether the credit is automatic. Google’s published Compute Engine terms require notice within 60 days and logs showing the downtime. They apply credits to future use and cap the aggregate credit for the relevant covered services. A negotiated SaaS agreement can adopt a simpler procedure when the vendor has the monitoring data and already knows a target was missed.

Is a credit enough?

A credit may be a proportionate remedy for a routine interruption. Consider separately data loss, confidentiality breaches, serious failings and repeated outages.

The agreement can address whether the credit is the sole remedy for ordinary downtime, is credited against damages, or operates alongside other rights. It can also provide escalation, separate remedies for other failures and termination after repeated serious incidents. The legal effect needs review under the governing law, including Polish law where applicable.

For a business-critical system, the ability to leave a persistently unreliable service may matter more than another discounted invoice.

Connect the SLA with support and recovery

Availability reports what happened over a period. Support and incident procedures tell the parties what to do during an outage. Define severity levels, first response, when work begins, progress updates, escalation, out-of-hours support, root-cause reporting and corrective actions.

Two further targets are important:

• RTO, recovery time objective: how quickly the system or process is to be restored.
• RPO, recovery point objective: how much recent data may be lost, for example the last 15 minutes.

A 99.9% target does not tell a customer whether it will recover data from five minutes ago or the previous day. Availability also does not replace patching and vulnerability handling, discussed in our CRA article on security updates.

Why the cloud SLA does not pass straight through

The application’s availability depends on the database, network, application code, APIs, authentication and deployment process. A figure promised by the infrastructure vendor is only one input.

Before agreeing a percentage, check single points of failure, redundant instances, recovery procedures, external dependencies, payment services, monitoring and any degraded operating mode. Vendor contracts should give the SaaS business the evidence and support it needs to meet its customer commitments.

The obligations at each level need not be identical, but the gap should be understood before an outage reveals it.

A worked example: a warehouse and an 800 PLN credit

This hypothetical case does not describe a client. A SaaS product supports orders and warehouse operations. The monthly fee is 8,000 PLN. The contract promises 99.9% monthly availability but excludes maintenance and third-party outages, uses only the vendor’s monitoring and makes a 10% credit the sole remedy. The customer must claim within seven days.

A database failure stops operations for three hours. Monitoring records two hours and forty minutes because the login screen remained visible for the first twenty minutes. Customers could not open an order during that period.

The cloud provider acknowledges its own failure, so the SaaS vendor invokes the third-party exclusion. The customer claims after nine days and is refused for missing the deadline. Even an awarded credit would be just 800 PLN, potentially far below the cost of manual work, delays and extra deliveries.

A more useful arrangement would measure the critical workflow, allow customer evidence, narrow the third-party exclusion and calculate credits automatically. Root-cause analysis, a corrective plan, repeated-failure exit rights, separate treatment of data loss and a warehouse fallback process would address different parts of the risk.

A review checklist

Make the percentage usable

A good SLA lets the parties reconstruct the outage, calculate the result and apply an agreed consequence. For a critical service, that sits alongside architecture, incident communication and a realistic exit route.

For help negotiating a SaaS agreement or maintenance terms under Polish law, see our IT and SaaS contract services or discuss the contract with us.