This week’s musings on tech contracts…
An article I read recently says, “Traditional warranties that cover product defects for a set time are giving way to SLAs [service level agreements], which focus on service availability and performance.” I’ve heard similar arguments elsewhere, in most cases citing the rise of software-as-a-service (SaaS) as the driver behind the shift. I’d be curious to know if anyone reading agrees or disagrees, in the comments. Have you seen a decline in warranties of functionality in IT contracts?
I think those views have it half right. A time-limited warranty makes less sense for SaaS than on-premise software because the latter traditionally includes a maintenance plan, which picks up after the warranty ends. Under maintenance terms, the vendor promises to keep the software working, even if the warranty’s expired. There’s no reason SaaS couldn’t include maintenance terms too (adjusted to fit software hosted by the vendor, rather than the customer). But that’s not the tradition in the IT industry. So SaaS customers need some other vendor promise to keep the software working: something that would kick in after the warranty ends – or just replace the warranty. The SLA, however, doesn’t do the trick.
Warranties and SLAs cover different topics
The subject matter of SLAs and warranties of functionality differ on three key fronts.
- Performance Obligation vs. Performance Target. IT warranties promise performance of computer systems. SLAs don’t. At least, the typical SLA doesn’t promise performance, and if you’re the vendor, you certainly shouldn’t. Rather, a typical SLA lists targets for performance, particularly uptime (e.g., five 9s). Missing those targets doesn’t breach the contract – any more than dropping your call breaches the phone company’s contract. Missing SLA targets just triggers credits: a discount off the next bill.
- All Functions vs. a Few Functions. The typical warranty of functionality covers all the operations of an IT system. A typical SLA doesn’t. The vendor usually “warrants that the software will function materially according to its Specifications.” And those specs generally cover all functions. The typical SLA, on other hand, only lists a few covered functions. SLAs usually target uptime and response and repair times, and they sometimes target technical issues like jitter and latency. That’s a tiny portion of the functionality covered by the specifications – by the warranty.
- Teeth vs. No Teeth. The typical SLA covers very little. Very little. SLAs almost always come riddled with exceptions and limits. Uptime may be 99.999%, for instance, but scheduled maintenance doesn’t count as downtime, and the vendor can schedule tons. Or the system isn’t considered down unless nothing works. One working function and its up. Unlike warranties, then, typical SLAs have no teeth. In fact, I’ve suggested in our trainings that SLAs work more as marketing tools than legal rights.
If you’re a SaaS customer, you probably don’t want to give up on your vendor’s promise of software performance. Nor do you want to give up on terms covering all the software’s operations, swapping them for an SLA covering only a few things, with no teeth.
SLAs have no remedy but credits, while warranties come with termination and other breach remedies – maybe even damages
The SLA usually limits its remedies to credits: limited discounts off the next bill. Failure to meet warranty standards, on the other hand, breaches the contract, so the injured party has remedies like termination and damages. A warranty’s remedy clause might reduce the odds of damages, but that’s usually in exchange for another valuable remedy. The vendor promises to fully fix or replace the malfunctioning software.
If you’re the customer and you swap your warranty for an SLA, you lose all those remedies: all the rights of the injured party in response to breach of contract.
SaaS is not more suited to SLAs than warranties
The article cited above and many others suggest warranties have faded because of the ongoing switch away from on-premise software to SaaS. I don’t see it.
Articles like those argue that SaaS customers care more about uptime, covered by the SLA, than about the subject-matter of warranties of functionality. But why would a SaaS customer care less than an on-premise customer about broad functionality: about whether most or all promised operations work. Uptime does matter to a SaaS customer, of course, but not to the exclusion of functionality.
A SaaS contract could offer a warranty substitute, but it’s not the SLA
Warranties usually expire. In the absence of a maintenance plan, that leaves the SaaS customer with no promise that the technology will work, other than the very limited terms of the SLA. SaaS customers need a solution, and a perpetual warranty would fit the bill. But warranties pack a lot of punch. In particular, failure of a warranty breaches the contract even if the vendor didn’t do anything wrong. It’s a no-fault clause. So vendors rightly hesitate to offer never-ending warranties.
The typical SaaS contract includes a different substitute, though we rarely think about it. Somewhere near the top, SaaS contracts usually say something like the following:
During the Term, Vendor shall provide the SaaS to Customer, operating materially according to its Specifications.
That promise picks up where the warranty leaves off, extending “materially according to its specifications” beyond any temporary warranty period, through the whole term.
For the customer, that’s better than an SLA. It’s a promise to keep all the software’s functionality in place, going far beyond the SLA’s limited promises about uptime and the like.
The advantages of SaaS
SLAs have advantages over warranties and over more limited promises of functionality, like the one above. In particular, you’ll usually find it easier to trigger credits than to collect damages or trigger other remedies for breach of warranty or other functionality promises. That means SLAs have independent value. It doesn’t mean they replace warranties.
For more on warranties and SLAs, please check out The Tech Contracts Master Class™. (Course 2 covers SLAs, and course 3 covers warranties – in each case, along with a lot more.)
THIS ARTICLE IS NOT LEGAL ADVICE. IT IS GENERAL IN NATURE AND MAY NOT BE SUFFICIENT FOR A SPECIFIC CONTRACTUAL, TECHNOLOGICAL, OR LEGAL PROBLEM OR DISPUTE, AND IT IS NOT PROVIDED WITH ANY GUARANTEE, WARRANTY, OR REPRESENTATION. LEGAL SITUATIONS VARY, SO BEFORE ACTING ON ANY SUGGESTION IN THIS ARTICLE, YOU SHOULD CONSULT A QUALIFIED ATTORNEY REGARDING YOUR SPECIFIC MATTER OR NEED.
© 2025 Tech Contracts Academy, LLC