Checkpoints for Reviewing SLA Clauses: Practical Issues on Service Levels, Incident Response and Refunds

Hello, I'm Noriaki Asato, Representative Attorney at LegalAgent.

When looking at contracts for SaaS, cloud maintenance and BPO, one often sees examples where the sales materials tout high figures such as "99.9% monthly uptime," while the contract provisions list exemptions and keep refunds to very small amounts. On the other hand, if a service provider readily accepts strict standards in order to prioritize winning customers, it may end up liable for damages even for events beyond its control, such as failures of external infrastructure. Reviewing SLA clauses goes beyond checking legal terminology; consistency must be judged with an eye to the system's redundancy, the maintenance structure and how users actually operate.

The Legal Nature of an SLA and Its Numerical Standards

An SLA (Service Level Agreement) is an agreement setting out the quality standards for a service that the service provider promises to the user. Contracts use headings such as service levels or uptime guarantees, and the typical design combines monthly uptime with service credits (fee reductions). A figure such as 99.9% uptime is one design example; there is no uniform legal standard that applies to all services.

Before checking the figures, determine whether the standard is legally a "contractual obligation" or merely a "target." The binding force of the clause differs greatly depending on whether failing to meet the target only requires holding improvement discussions, results in a fee reduction or refund, or leads directly to termination of the contract or damages.

The main items that form the axis of the review are as follows:

• The calculation period and formula for uptime, and the exclusions for scheduled downtime and external factors
• Initial response times and recovery time objectives according to incident severity levels
• The method for calculating service credits and the balance with actual business losses

Also confirm the scope of services covered. The substantive scope of the guarantee differs depending on whether it refers only to the production server environment or also includes the admin console, APIs, mobile apps and the customer support desk. As for the uptime formula, read closely whether it excludes scheduled downtime for regular maintenance, user configuration errors, failures of third-party clouds and force majeure from the denominator or numerator of the calculation.

Incident Response Procedures and Fee Reductions and Refunds

For the procedures when a system incident occurs, check whether initial response times, recovery time objectives and the frequency of status reports are specified for each severity level. If the authority to determine severity rests solely with the provider, it may diverge from the user's actual experience of business disruption. In addition, "24-hour intake" and "24-hour response" at a support desk are different in substance, so it is essential to tell from the provisions whether the desk merely receives contacts or whether engineers act to restore service.

For service credit and refund procedures, check the conditions for eligibility, the deadline for claims, the cap on the amount, and whether the credit is deducted from the next month's fees or refunded. The user should assess whether it will be an effective remedy, and the provider should confirm whether granting credits is positioned as the sole remedy that excludes claims for damages, or whether credits may be claimed together with damages. The mere fact that credits are provided for does not automatically exclude other claims, so also check the content and effect of any clause limiting remedies. For incident reports, including a deadline for submission, root cause analysis and an obligation to present measures to prevent recurrence helps support the user's external explanations and its dealings with regulatory authorities.

The user's duty to cooperate is also a premise. Reasonably define the scope within which the provider is exempt if the user does not maintain the recommended environment, properly manage access rights or provide information for incident investigations. However, check that the provision does not go so far as to exclude incidents unrelated to the user's lack of cooperation. Where failures to meet the standard recur, consider preparing escalating measures that go beyond one-off refunds, such as the submission of an improvement plan, a right to terminate the contract and the assignment of a priority support desk.

Practical Risks for Users and Providers

On the user side, check whether the SLA adequately covers the company's business continuity plan (BCP) and actual business risks. For core systems, what matters is not only the uptime figure but also whether the frequency of data backups, procedures for alternative operations and a direct contact route during incidents are in place. If the cap on service credits is extremely small compared with the company's potential lost revenue, do not rely solely on the compensation under the contract; consider in parallel backups on your own side and the use of damage insurance.

On the provider side, verify whether the company has the operational structure to perform the agreed SLA. If the contract promises a prompt initial response but there is no night and holiday monitoring system, or incident detection relies on manual work, the provider takes on the risk of breaching the clause. Furthermore, clauses under which even a minor delay leads to termination or unlimited damages can impose an excessive burden, so confirm that they are combined consistently with the limitation of liability clause and the force majeure clause. For both sides, deciding who will communicate the situation to whom, by what method and how often makes it easier to make decisions based on the same information during an incident.