Briefing · Business & Contracts · Healthcare Formation

Enforceable SLAs: Remedies That Actually Bite

An SLA is useful only if the metric is measurable, the exclusions are narrow, the reporting is auditable, and the remedy changes behavior. Draft service levels as an operating control, not marketing language.

By Lincoln Square Law · 10-minute read

Define the service before defining the percentage

“99.9% uptime” is not a complete obligation. The agreement has to define the service boundary, measurement source, measurement period, denominator, excluded events, maintenance windows, and whether partial degradation counts as downtime. A vendor can satisfy an attractive percentage while a critical workflow remains unusable if the metric measures the wrong component. Start with the customer function that matters, then design the metric around that function.

For response and resolution SLAs, define when the clock starts, what information the customer must provide, when the clock pauses, severity levels, and the difference between workaround, restoration, and final resolution. A vendor should not be able to downgrade severity unilaterally after the ticket opens. If the service supports regulated operations, patient care, payroll, payment processing, or security, the severity model should reflect operational impact rather than only the vendor’s internal classification.

Make the measurement independently auditable

The contract should identify the system of record for SLA performance and give the customer access to enough data to verify the result. Monthly dashboards are useful, but they should not be the only evidence when the vendor controls the dashboard. Preserve incident logs, ticket timestamps, monitoring records, and maintenance notices for an agreed period.

Require the vendor to explain material discrepancies and correct erroneous reports.

Avoid clauses making vendor calculations “final and binding” unless there is a meaningful dispute mechanism. If the customer has its own monitoring, specify how conflicting measurements are reconciled. The goal is not to litigate every minute of downtime. It is to make the metric credible enough that both sides know a missed service level will be visible and provable.

Use credits as the floor, not necessarily the ceiling

A service credit can create a simple, automatic consequence for ordinary SLA misses. It works best when credits scale with severity or repeated failure and are applied without requiring a formal breach notice for each event. But a credit that returns one or two percent of a monthly fee may not matter when an outage causes materially larger operational loss.

Decide whether credits are the exclusive remedy for routine SLA failures, and identify the circumstances that move the issue into broader contractual remedies.

For transactions in goods governed by Article 2 of the Illinois Uniform Commercial Code, section 2-719 lets the parties add to, substitute for, or limit the Code’s remedies. Three features matter for SLA drafting. First, an agreed remedy is optional unless the contract expressly makes it exclusive, so a credit schedule that never says it is the sole and exclusive remedy will generally sit alongside other remedies rather than replace them. Second, if circumstances cause an exclusive or limited remedy to fail of its essential purpose, the Code’s general remedies become available. Third, consequential damages may be limited or excluded unless the limitation is unconscionable, and limiting commercial loss is not presumptively unconscionable. The Illinois Supreme Court evaluates a consequential-damages exclusion on its own terms, so a limited remedy that fails does not automatically void a separate consequential-damages waiver.

Whether section 2-719 applies at all depends on the transaction. For contracts that mix goods and services, Illinois courts ask whether the predominant purpose is the sale of goods or the provision of services. Many hosted-service and support arrangements are structured primarily as services, but classification is fact-specific and depends on the governing law. Even where Article 2 does not apply, the drafting lesson holds: the remedy structure should be coherent with the promised performance and the governing law. Do not label a nominal credit the exclusive answer to every possible failure without analyzing the effect.

Size credits as compensation, not punishment. Section 2-719 is expressly subject to the Code’s provision on liquidated damages, and outside Article 2 Illinois common law likewise will not enforce a stipulated-damages term that operates as a penalty for nonperformance or as a threat to secure performance. Illinois courts generally ask whether the parties intended to settle damages in advance, whether the amount was a reasonable forecast of likely harm when the contract was made, and whether actual damages would have been difficult to prove. A credit schedule that escalates with severity or repeated failure is easier to defend when each step tracks foreseeable operational impact. Do not rely on a “not a penalty” label alone; the analysis turns on the amount and its relationship to anticipated harm.

Add escalation and termination rights for chronic failure

The strongest SLA remedy is often not money. It is control over what happens next. Require a root-cause analysis after defined incidents, a corrective-action plan for repeated misses, executive escalation after a threshold, and termination rights if failures recur over a rolling period. Define chronic failure objectively: for example, missing a critical SLA in two of three months, three quarters in a year, or a specified number of Severity 1 incidents. The trigger should be measurable and should not depend on the vendor conceding breach.

Termination rights should address transition. A customer that can terminate but cannot export data, obtain reasonable migration assistance, or keep the service running during transition has limited leverage. Tie the SLA remedy to data-return obligations, transition assistance, and a defined wind-down period. If the service is hard to replace, consider requiring extended support at existing rates after a chronic-failure termination while the customer migrates.

Coordinate SLAs with limitation of liability and indemnity

Read the SLA and the limitation-of-liability section together. If credits are excluded from the cap, say so. If credits count against damages, say so. If a security incident is governed by a separate incident-response or indemnity regime, avoid language that converts it into a mere uptime failure. Likewise, do not allow the SLA schedule to override stronger remedies in the main agreement unless that is intentional.

Insurance and indemnity are not substitutes for performance remedies. Insurance may respond after a covered loss. An SLA is supposed to influence performance before the loss becomes systemic. Use each tool for its function. Draft the commercial consequences so the vendor has a reason to invest in reliability, while preserving proportionate remedies for events that create materially different kinds of harm.

Our briefing on limitation-of-liability architecture covers caps, carve-outs, and Illinois limits in more detail, and our briefing on the data terms stack covers how DPAs, BAAs, and security exhibits fit with the main agreement.

Govern exclusions and force majeure narrowly

Maintenance, customer-caused events, internet failures, force majeure, third-party platforms, and beta features are common SLA exclusions. Define them carefully. Planned maintenance should require advance notice and usually be limited to specified windows. A vendor should not exclude a third-party dependency when that dependency is part of the service architecture the vendor selected and manages. Customer-caused exclusions should apply only to the extent the customer actually caused the failure.

Require mitigation even when an exclusion applies. How far a force-majeure clause excuses performance depends on its wording and the governing law, so the listed events, the causation standard, and any notice and mitigation conditions deserve the same precision as the SLA metric itself. A force-majeure event may excuse strict performance, but it should not erase duties to communicate, activate continuity plans, restore service, protect data, and cooperate with the customer.

The most useful SLA schedule is one the operations teams can run during a real incident, not one that only lawyers can interpret after the fact.

Align the SLA with incident management

The contract should use the same severity taxonomy that operations use during incidents. If the support team calls an event “P1” while the contract calls it “Severity 1” and the definitions differ, measurement will break precisely when the service is failing. Map the terms, define who can declare severity, and require prompt notice when the vendor changes classification. The incident-management process should automatically preserve the timestamps needed to measure the SLA.

For critical incidents, specify communication cadence and audience. A promised response within fifteen minutes is of limited value if the response is an automated ticket acknowledgment. Define whether the vendor must provide a qualified engineer, incident commander, executive contact, or written update. Require a post-incident report for material events with root cause, timeline, remediation, and recurrence-prevention commitments.

Draft service credits so they can actually be claimed

A credit process can fail through procedure even when the metric is clear. Avoid short claim windows, burdensome documentation that the vendor already possesses, or requirements that the customer identify every minute of downtime before the vendor will calculate a credit. For material services, consider automatic credits based on the vendor’s own reporting, subject to customer challenge. State when the credit appears and what happens if the agreement terminates before it can be applied.

If credits are cumulative across metrics, say so. If they are capped, state the cap clearly. Decide whether chronic failures that trigger termination also generate credits. Most importantly, make sure the credit does not waive separate claims for breaches outside the SLA, such as confidentiality, security, intellectual-property, or compliance failures.

Test the SLA against a realistic failure scenario

Before signature, run one scenario through the schedule: a critical service fails for four hours during a peak period, the vendor initially labels it lower severity, a cloud subcontractor is involved, and the customer needs to migrate data if the problem recurs. Determine when the clock starts, whether the event is excluded, what updates are due, what credit applies, whether executive escalation is triggered, and whether the event counts toward chronic-failure termination. If the answers require creative interpretation, the SLA is not operationally complete.

This exercise also exposes conflicts between schedules. The main agreement may say one thing about notice, the security exhibit another about incidents, and the SLA a third about severity. Resolve the hierarchy before execution.

During an outage, teams should not have to decide which document controls while the business is already under pressure.