Service Level Agreements: What the Uptime Guarantee Actually Delivers

A service level agreement is the part of a SaaS contract that promises the software will be available and performing. It usually appears as an exhibit or attached policy, states an uptime commitment such as 99.9 percent, and describes what the customer receives if the provider falls short. To a customer evaluating the product, it reads as the provider standing behind its service.

The SLA usually delivers less than it appears to. The uptime number draws the attention, but the operative terms are in the definitions, the exclusions, and the remedy. Those provisions frequently combine to make the headline commitment far less protective than it looks. A customer that reads only the percentage can end up with a guarantee that is difficult to trigger and worth little when it pays out.

Reading an SLA for what it actually guarantees comes down to four things: how uptime is measured, what is excluded from the measurement, what the customer gets when the commitment is missed, and what the customer has to do to collect. Each one can quietly narrow the protection.


How Uptime Is Measured

An uptime commitment is only as meaningful as the definition of uptime that supports it. The same 99.9 percent figure can mean very different things depending on how availability is defined and measured.

The measurement period matters. A 99.9 percent commitment measured monthly allows roughly 43 minutes of downtime per month. The same commitment measured annually allows roughly 8.7 hours of downtime in a year, which could occur all at once. A customer that assumes a monthly measurement when the contract specifies annual has a very different level of protection than it thinks.

The definition of downtime matters just as much. Some SLAs count the service as down only when it is completely unavailable to all users. Under that definition, severe degradation that makes the service unusable in practice, but not technically unavailable, does not count against the uptime commitment. A service that is running but too slow to use may be fully compliant with an SLA that measures only complete unavailability.

Who measures also matters. Many SLAs provide that the provider’s own monitoring systems are the definitive record of availability, which can leave a customer that experiences an unrecorded outage with no practical way to establish that the downtime occurred.

The uptime percentage is not the commitment. The commitment is the percentage plus the measurement period, the definition of downtime, and the source of measurement, read together. Before relying on a 99.9 percent number, confirm what counts as downtime, over what period it is measured, and whose records govern.


What Is Excluded from the Measurement

Every SLA excludes certain downtime from the uptime calculation. Some exclusions are reasonable. Others are broad enough to absorb much of the downtime a customer would actually experience.

Scheduled maintenance is the most common exclusion. Downtime during a defined maintenance window does not count against the commitment. This is reasonable in principle, but the terms of the maintenance exclusion determine how much it gives away. An exclusion for maintenance during defined off-hours windows with advance notice is narrow. An exclusion for any maintenance the provider designates, at any time, with minimal notice, can remove a substantial amount of downtime from the calculation.

Force majeure and third-party failures are also commonly excluded. Downtime caused by events outside the provider’s reasonable control is excused. The complication is that modern SaaS usually runs on third-party infrastructure, and an exclusion for downtime attributable to the provider’s hosting or infrastructure vendors can shift a meaningful category of outages outside the commitment. If the provider’s cloud host has an outage, the customer’s service is down, but the SLA may not count it.

Other frequent exclusions cover downtime caused by the customer’s own systems or configuration, by the customer’s equipment or connectivity, or by use of the service outside its documented scope. These are generally reasonable, but each one narrows the set of outages for which the provider is responsible.

The exclusions are where the uptime commitment is defined in the negative. Read them as carefully as the percentage. The question is not whether exclusions exist, because they always do, but whether the exclusions taken together leave the provider responsible for the outages that would actually affect the business.


What the Customer Gets: Service Credits as the Sole Remedy

When a provider misses the uptime commitment, the standard remedy is a service credit: a percentage of the fees for the affected period, applied against future invoices. The credit usually scales with the severity of the miss, so a larger shortfall produces a larger credit.

Two features of the service credit remedy limit its value. The first is size. Service credits are typically small, often a single-digit or low double-digit percentage of the monthly fee for the affected month, scaling up only for severe and sustained outages. The credit rarely approaches the actual cost to the customer of the downtime. A business that loses a day of operations because a critical system is unavailable receives a credit measured against its subscription fee, not against the business it lost.

The second feature is exclusivity. SLAs almost always provide that the service credit is the customer’s sole and exclusive remedy for a failure to meet the service level. That language matters. It means the customer cannot pursue damages for the downtime beyond the credit, even if the actual harm was many times larger. The service credit operates as a ceiling on recovery rather than a floor, capping what the customer can collect no matter how costly the outage. From the provider’s side, this structure is understandable. An uptime miss should not create open-ended exposure unrelated to the fees charged. That is why providers treat the sole-remedy credit as a core term.

For business-critical systems, the gap between the service credit and the actual cost of an outage is the central issue in the SLA. A customer whose operations depend on the service should consider whether a sole-remedy service credit is adequate, or whether the contract needs a different mechanism for serious or repeated failures, such as a termination right after a defined number of missed months.

The service credit is the whole remedy, not part of it. Evaluate it against the cost of an outage to the business, not against the subscription fee. If the service is critical, a sole-remedy credit measured against fees may not be adequate, and the more important protection may be a termination right for chronic failure.


The Takeaway

The uptime percentage is the most visible part of an SLA and the least informative on its own. What the SLA actually guarantees depends on how uptime is measured, what downtime is excluded, what the customer receives when the commitment is missed, and what the customer has to do to collect. Each of those can narrow the protection, and together they often reduce a headline commitment to something far more limited.

For a service that is not business-critical, a standard SLA with a sole-remedy service credit may be perfectly acceptable. For a service the business depends on, the SLA deserves the same scrutiny as any other risk-allocation provision in the contract. The percentage is where reading the SLA starts, not where it ends.

This post is general information only and does not constitute legal advice. For questions about a particular agreement or service level commitment, contact Cruxterra Law Group.

Next
Next

Knowledge and Materiality Qualifiers: How a Strong Representation Gets Hollowed Out