4 ms·

I deal with SLAs in my job all the time. After over a decade negotiating uptime SLAs, I'm firmly convinced that the best protection against downtime is a huge,

I deal with SLAs in my job all the time. After over a decade negotiating uptime SLAs, I'm firmly convinced that the best protection against downtime is a huge, vocal userbase, and the best remedy for downtime is an unqualified termination right and refund of prepaid fees. An SLA (even with severe penalties) is certainly setting up the right incentives on paper, but in practice it has little effect on the results. Why? Because enforcing a promise on a piece of paper is bothersome, expensive and sours the relationship. Also, saying you'll pay 50x penalty is only half the story. What are the triggering events that entitle customers to payment? Is the SLA measured end-to-end (i.e., from the user's endpoint to yours)? Is the SLA penalty cumulative? Can your customers actually profit from your downtime (i.e., you would end up owing them more cash than they paid you)? Without more details, your post suggests that each fraction of a second of downtime experienced by any single user of your service entitles them to a credit of 50x what they paid for that fraction of a second. Is that your policy?

justinsb 15y ago
Thanks for the expert input. This is exactly why we don't have a SLA at FathomDB, because I don't think that they're worth the paper they're written on. It seems like you almost agree (?) Most cloud providers (including FathomDB) charge by the hour anyway, so you have termination rights for any reason, and there are no prepayments to refund. We think that 'doing the right thing' is the only workable policy, and it shouldn't require an outcry from a vocal userbase. We should have handled the outage better, and we're making a big payment to demonstrate that. We're not going to let any new customers use a system where we can't be confident in its uptime (MySQL on AWS); we're building a new system in which we can be confident.
- sunchild 15y ago
  Dead on. I went back and re-read the article, and yes – we are in agreement. It's about doing whatever it takes to keep the relationship with your customers on an even keel. I couldn't agree more that SLAs are generally bad for customers, even though the perception is the opposite. I can't tell you how many times I've had a client demand an SLA from their vendor, and when that SLA arrives, it reads like a commitment, but actually it's impossible to fail. And these almost always are wrapped in "exclusive remedy" language, which quite literally means the customer would be better off without it. The devil is in the details. Cheers!

justinsb 15y ago

Thanks for the expert input. This is exactly why we don't have a SLA at FathomDB, because I don't think that they're worth the paper they're written on. It seems like you almost agree (?) Most cloud providers (including FathomDB) charge by the hour anyway, so you have termination rights for any reason, and there are no prepayments to refund. We think that 'doing the right thing' is the only workable policy, and it shouldn't require an outcry from a vocal userbase. We should have handled the outage better, and we're making a big payment to demonstrate that. We're not going to let any new customers use a system where we can't be confident in its uptime (MySQL on AWS); we're building a new system in which we can be confident.

sunchild 15y ago
Dead on. I went back and re-read the article, and yes – we are in agreement. It's about doing whatever it takes to keep the relationship with your customers on an even keel. I couldn't agree more that SLAs are generally bad for customers, even though the perception is the opposite. I can't tell you how many times I've had a client demand an SLA from their vendor, and when that SLA arrives, it reads like a commitment, but actually it's impossible to fail. And these almost always are wrapped in "exclusive remedy" language, which quite literally means the customer would be better off without it. The devil is in the details. Cheers!