4 ms·

100% uptime is not an operational requirement – it's contractual. A client that demands 100% uptime isn't being unreasonable; they're looking for a contract re

100% uptime is not an operational requirement – it's contractual. A client that demands 100% uptime isn't being unreasonable; they're looking for a contract remedy (most likely a termination right) if/when the site goes down. 1. "Uptime" is defined in many, many ways. In the OP's article, it's the definition of uptime that seems unreasonable. Normally, the demarc points for the network segments and equipment being measured for uptime are entirely within the provider's control. In the OP article's update, the client clarified that 100% uptime only applies when hosting is cut over to the provider's site – something they are (theoretically) capable of controlling. 2. Remedies for failing the uptime requirement are different for nearly every agreement. Often SLA credits are the exclusive remedy. Sometimes the customer has a termination right (either express, or through the termination for cause provision). The remedy is probably more important than the uptime percentage. You'd be surprised how many big name web apps offer 100% uptime as a matter of contract, knowing that it's a near-impossible operational goal. It's a matter of taking on the risk of your customer leaving you or claiming SLA credits, or whatever remedies you agree upon.

sunchild 15y ago
EDIT: I've represented a whole lot of customers of web services over the years (IAAL). The big lesson in this area for me is: (1) customers rarely invoke SLA credits, preferring instead to "work it out" at the relationship level, and (2) most provider off-the-shelf SLAs are so full of holes and tricky thresholds that they are effectively useless. On this last point, beware the 100% or five nines or other unreasonably high uptime commitment. When you get into the details of the SLA (the demarcs, the qualifications for obtaining credits, the remedies for failure), you will almost always find that there is no realistic remedy at all. N.B. Meant to edit my comment above, not self-respond.
nroach 15y ago
Laypersons often misunderstand that there's a difference between promising 100.00000% and delivering 100.00000%. The client needs to understand what their contractual remedy is when the promise falls short, and the method that will be used for evaluating the difference between the promise and the delivery.
deleted 15y ago
[deleted]

sunchild 15y ago

EDIT: I've represented a whole lot of customers of web services over the years (IAAL). The big lesson in this area for me is: (1) customers rarely invoke SLA credits, preferring instead to "work it out" at the relationship level, and (2) most provider off-the-shelf SLAs are so full of holes and tricky thresholds that they are effectively useless. On this last point, beware the 100% or five nines or other unreasonably high uptime commitment. When you get into the details of the SLA (the demarcs, the qualifications for obtaining credits, the remedies for failure), you will almost always find that there is no realistic remedy at all. N.B. Meant to edit my comment above, not self-respond.

nroach 15y ago

Laypersons often misunderstand that there's a difference between promising 100.00000% and delivering 100.00000%. The client needs to understand what their contractual remedy is when the promise falls short, and the method that will be used for evaluating the difference between the promise and the delivery.

deleted 15y ago

[deleted]