Sole and Exclusive Remedy: The Clause That Caps Every Cloud Claim
September 23, 2026
An eight-hour outage on a $5,000 a month service produces a credit of $1,250 at the usual 25% tier. The lost sales, the weekend your engineers spent on a bridge call, the customers who quietly left: none of it is recoverable under the same document. That answer is not an accident of billing; it is drafted. The clause is called sole and exclusive remedy, and every major provider states it with the same intent: the credit is the entire compensation for the outage, and nothing else is owed. Three further clauses stand behind it, a warranty disclaimer, a bar on indirect losses, and a damages cap. Together they set the maximum an outage can ever be worth, and the credit is the only part that moves.
The clause, in each provider's own words
| Provider | What the document says |
|---|---|
| AWS | The Compute SLA states it sets forth "your sole and exclusive remedies, and AWS' sole and exclusive obligations"; the wording across other SLAs is blunter still, with Redshift promising the receipt of service credits as "your sole and exclusive remedy" |
| Microsoft | "Service Credits are your sole and exclusive remedy for any performance or availability issues for any Service under the Agreement and this SLA. You may not unilaterally offset your Applicable Service Fees for any performance or availability issues." |
| Every product SLA closes with the same sentence: "This SLA states Customer's sole and exclusive remedy for any failure by Google to meet the SLO" | |
| DigitalOcean | Its SLA pages put the same idea in billing terms: credits are non-refundable, apply only to charges for the affected resource, and land on future invoices |
The language differs; the effect does not. The credit is not a starting point for a bigger claim. It is the finish line.
The three walls behind the remedy clause
The customer agreement every account accepts at signup builds the rest of the structure, and it is worth reading as one stack.
The warranty section comes first. AWS states the services are provided "as is" and disclaims, among others, any warranty that they "will be uninterrupted, error free or free of harmful components." Google's Section 11 disclaimer does the same work. No provider promises you will not have an outage; the SLA only prices the ones that happen.
The liability exclusions follow. AWS Section 9.1 rules out liability for indirect, incidental, special, consequential or exemplary damages, for "the value of your content", for loss of "profits, revenues, customers, opportunities, or goodwill", and even for "unavailability of the services", with a parenthesis that keeps service credits intact. Google's Section 12.1 excludes indirect, consequential, special, incidental or punitive damages, and lost revenues, profits, savings or goodwill. The downtime costs that sting most sit squarely inside those lists.
The damages cap closes the structure. Aggregate liability is limited to the fees paid for the services that gave rise to the claim during the twelve months before it. That is AWS Section 9.2 and Google Section 12.2, with the Google carve-out that free services are capped at $5,000. Microsoft's version lives in the SLA's general terms: credits attach only to the affected resource or tier, and you cannot unilaterally offset them against your bill.
The stack reads in order: the SLA says what an outage is worth, the remedy clause says the credit is all you get, the warranty section removes any promise that service will stay up, and the damages cap sets the outer ceiling near a year of spend. Three of the four layers sit in the agreement you accepted at signup. The credit is the only one that moves, and it only moves if somebody files.
The arithmetic that follows
A worked example makes the ceiling concrete. The same $5,000 a month workload loses eight hours, the month lands at 98.889%, and the credit pays $1,250. Suppose that incident also pushed $300,000 of orders off a transaction system. The lost revenues are excluded by both agreements above; the cap anchors any dispute at the affected service fees for the past twelve months; and the forum for it would be a contract dispute, not a support ticket. Every practical route to more than the credit runs through clauses that were drafted to close it.
None of this makes the credit worthless. It is the only mechanism in the entire structure designed to pay anything, and the schedule is real: 10% to 100% depending on service and tier, $1 minimums at AWS, five-figure payouts on enterprise bills during real incidents. What it does mean is that the gap between the credit and the true cost of downtime is yours by design, and should be priced that way.
What the clause does not do
Two boundary cases are worth keeping straight. First, the agreements themselves preserve whatever cannot be limited by law: Google's Section 12.3 lists fraud and fraudulent misrepresentation as unlimited liabilities, and AWS Section 9.2 keeps "any party's liability to the extent such liability cannot be limited under applicable law". Second, the clause channels claims into the credit process, it does not eliminate them: deadlines of 30 days to two months, evidence requirements and per-service schedules still apply, and all of it still has to be filed by you.
The practical response fits on one line. Claim what the structure pays, and buy availability for what it does not. If you hold a negotiated enterprise agreement, its amendments are the only place those walls can be moved; the standard terms are the default for everyone else. Then do the comparison that matters: if a modelled bad day costs more than a year of the affected service's fees, the contract will not close the gap, and redundancy is the remedy the clause leaves you. UptimeAudit works the part of the structure that does move, tracking the big four's health feeds and drafting the claims that the documents actually pay.