Lev Lazinskiy

100% Uptime*

I have been a customer of Vultr on and off since March 2015. I have been running a VPS (Virtual Private Server) server on one platform or another since 2011 and I spent some time working in operations for a large VPS provider. In addition I briefly started my own VPS service last year. My experience with Vultr has been mostly good. Their support is responsive, service is mostly stable, and aside from a few expected hiccups related to abuse on a shared host, things have been great. Recently while browsing their home page I noticed that they offer a 100% uptime SLA.

I was pretty intrigued by this. My previous experience has led me to believe that achieving a true 100% SLA is practically impossible. Hosting is a frustrating and difficult business where something will always go wrong and there are way too many variables beyond any one companies control to be able to promise 100% uptime. So I thought to myself, what is Vultr doing that no one else can?

Well, based on my most recent interaction with their account management team, the short answer is “Nothing”. As far as I can tell this 100% Uptime* guarantee is just a marketing ploy that is intended to make Vultr look like a great value without actually being one in the same way that mail in rebates (remember those?) made things seem very cheap until you had to actually go through the process of sending in the rebate and hoping that the return check actually arrived.

Recently I got the following email from Vultr:

We have detected a system issue with the node hosting the instances listed above. Our engineering team applied system updates and scheduled a brief maintenance window to perform a node restart. Date and Time: Jan-13-2017 11:00 UTC (Jan-13-2017 03:00 Local Time) Please note: This event will reboot your affected instances. Your data and configurations will not be affected by the reboot.

The total downtime was less than 5 minutes (awesome!) and everything came back online without incident (double awesome!). According to their SLA chart I would be eligible for 12 hours of credit. I opened a ticket (on Saturday morning) and asked how the SLA process worked. I was informed that this question had to be answered by a member of the account management team and they would get back to me on Monday. No worries, totally get that, I thanked the support engineer for their time and waited patiently until Monday.

This morning I get the following email from their account management team:

If you experience any disruption in service that is not scheduled maintenance you would have to open a ticket to request SLA credit. Further information can be found here: https://www.vultr.com/legal/sla/

In order to receive any credit offered under this SLA, You must initiate a support ticket related to the event AND expressly request that We issue a credit. DO NOT ASSUME THAT WE ARE AWARE OF YOUR OUTAGE. Your outage may be wholly unrelated to Vultr's services, so unless You contact Us via a support ticket, We may not be aware any problem exists.

If Vultr needs to perform scheduled maintenance on your node, this is exempt, unless of course it takes us more than 10 minutes!

In accordance with the procedure outlined below, you must initiate a support ticket and request that a credit be applied to your account. Merely initiating a support ticket related to an outage will not result in any credit to your account.

The most important questions that I had were why couldn’t the support team send me that link and why isn’t there an asterisk next to the 100% SLA on the marketing site?

To be honest, I could care less about the actual reimbursement. The server itself costs a trivial amount of money per month, and the downtime was not that disruptive to me. The thing that really makes me frustrated is this deceptive and seemingly marketing driven SLA copy. Its makes me feel that I cannot in good conscience recommend this service to anyone else. If you are going to make such a grand claim as a 100% SLA you should either live up to it (which includes not making the customer jump through hoops in order to use it) or not make these types of promises at all.