HATR Consulting

Today I’m writing the third and final post on uptime/downtime; a significant aspect of SaaS/cloud contracts. Find the first part here, wherein I discuss the fundamentals of the uptime/downtime issue. Find the second part here, wherein I discuss the concept of the credit remedy for excessive downtime.

Today, I dive deeper into the calculation of uptime/downtime and carveouts common to the calculation.

From the first part of this series, it may seem obvious/clear how to calculate downtime. There are 720 hours in a 30-day month. One hour of downtime = 0.1% downtime (1/720). Ten hours of downtime = 1.4% downtime. Forty hours (a full work week) of downtime = 5.6% downtime. Eighty hours of downtime = 11.1% downtime. You take your downtime %, look at the applicable credit band, and demand your credit – simple, right?

Not all the time. Many downtime provisions include exceptions, or carveouts, to what qualifies as downtime. The most common example is schedule maintenance. If the vendor has to close the applicable for a few hours for maintenance, they will say that does not qualify as downtime for credit calculation purposes.

That arguably makes sense – customer’s benefit from vendors doing maintenance, and so you do not necessarily want to punish vendors for doing so.

Another common carveout are “force majeure” events, sometimes referred to as acts of God – events causing downtime that are not within the control of the *vendor* (the party reference is critical). In this carveout, there could be an event that causes downtime, but for which the vendor couldn’t have really prevented. Example: upstream downtime, like the vendor’s hosting platform is down. While you may think – this is reasonable, there’s nothing the vendor can do about this, I don’t necessarily agree. The result is the same – the client/customer has no access to the service they’ve paid for – they’re paying for nothing – and that’s a problem. Flip side – the vendor is getting paid for *not* providing service.

One more carveout that I want to discuss: “unscheduled maintenance.” Some firms position “unscheduled maintenance” as unqualified downtime, meaning, they can claim downtime as unscheduled maintenance, and the client has no recourse – no refund, no credit. Compare this to *scheduled* maintenance, where the vendor notifies the client of the upcoming downtime, and the client can schedule business accordingly. With unscheduled maintenance, there is no opportunity for the client to work around the downtime – it’s a surprise. I personally take the position that “unscheduled maintenance” *should* qualify as downtime.

There is a lot more that I can talk about with respect to uptime and downtime. While important to writing a contract, the specifics are really up to a business decision – whether the person/company spending the money accepts the recourse the vendor offers in terms of excessive downtime. With the recent events of global blue screens of death, it seems pretty clear that this is an important contract provision to pay attention to.

Do you have any questions on uptime/downtime? Any other contract provisions you have questions about? Was this 3-part series helpful? Let me know in comments.