SLA clause review checklist

Hello, this is Legal Agent.

Sales materials often promise 99.9% uptime, and the contract text can turn out to apply that number only under limited conditions, with a modest credit attached. On the other side, a provider that accepts a strict SLA to win the deal can end up contractually answering for outages entirely outside its control.

What the number actually measures, and whether it binds

The more important question than the percentage itself is whether it is an aspiration or a contractual obligation: does falling short simply trigger a discussion, or does it generate a service credit, a termination right, or damages? The scope matters too, whether the commitment covers only the production environment or extends to the admin console, API, mobile app and support desk, and so does how the uptime figure is calculated, including whether planned maintenance, user misconfiguration, third-party outages or force majeure are excluded from the numerator or denominator.

Incident response and its limits

Severity-based response and resolution targets, and who decides severity, should be defined rather than left to the provider alone. "Available 24 hours" and "responded to within 24 hours" are different promises, so the clause should make clear whether an inquiry is merely received or actually worked by an engineer. Service credits should state the trigger, the cap, and whether they are deducted from the next invoice or refunded, and whether they are the customer's sole remedy or sit alongside a separate damages claim; incident reporting should specify the deadline for root-cause analysis and any remediation plan.