Uptime Guarantee - Good or Bad Idea?

Exactly. Now you are learning. When the restriction is an artificial quota created by the provider, as found in such hosting resources as email accounts, databases, sites/domains we call those things unlimited when that quota restriction is removed

this is why we run our unlimited resources the way we do, so that a client gets a base quota, but when they require more they ask us in a ticket, which means that we have more control on the amount of actual email accounts etc. on our servers
 
this is why we run our unlimited resources the way we do, so that a client gets a base quota, but when they require more they ask us in a ticket, ...

That's a cool management style. Hopefully Blue won't create a ticket calling you a liar. :crazy:
 
Last edited:
That's a cool management style. Hopefully Blue won't create a ticket calling you a liar. :crazy:

its the best way we found to control unlimited resources as in the early days we have had resources abused by clients when we did not control the amount of resources per client.
 
its the best way we found to control unlimited resources as in the early days we have had resources abused by clients when we did not control the amount of resources per client.

Another way along similar lines to confugure server for a hosting plan with unlimited web space is to set quota with a Soft Limit and no Hard Limit (in Linux Hard Limit = 0, in Windows Quota = No Limit) and configure OS or monitoring software to send an email to admin when a user reaches the Soft Limit. That will signal auditing time
 
Last edited:
Another way along similar lines to confugure server for a hosting plan with unlimited web space is to set quota with a Soft Limit and no Hard Limit (in Linux Hard Limit = 0, in Windows Quota = No Limit) and configure OS or monitoring software to send an email to admin when a user reaches the Soft Limit. That will signal auditing time

we dont offer Unlimited Space or Bandwidth just the secondary resources such as emails, ftp, MySQL etc. which we do have configured on the server to alert us when they reach 60/70/75/80/85/90 percentand the client will also get the alert email
 
It's a good idea IF you can actually abide by it. If you don't - simply be prepared to pay out.

It's not even that. Uptime SLA can be useless if it it goes down all the time. E.g. if you go down 1 min a day, that's still at max 31 min per month, which is <99.9% Uptime some offer. However, this can be very annoying.
 
It's a good idea IF you can actually abide by it. If you don't - simply be prepared to pay out.

There is nothing to abide by except an SLA, and since its the host creates it the host would be prepared to pay out. The cost in miniscule -- a small percent of a small monthly payment.
 
You have to have an uptime guarantee. How you setup your SLA is what can cause issues though. PLus so many factors such as should you honor their monitor's reading or what.

When I was a newbie host back in the day I made an SLA where if uptime fell below 99% in a month and the customer noticed it of course, I would refund a minimum of 10% of their monthly fees. Now this only was applicable if they had not reached their ddos protection threshold and they had live graphs of that to see.

Boy what a mistake, with apache/webserver restarts, network farts (sorry, no other word I can think to describe when your network or routing takes a dive for a second to a few minutes) and general server reboots and such you will be lucky to keep at 99.99. God forbid someone gets ddosed on your server and its on a shared ip.

Anyway, when I did this, since my average plan was about $90-379 for ddos protected hosting so some customers (not all but some) would setup monitoring on 30 second delays or even less, watch their attack stats like a hawk, The minute they seen the SLA failing they would call demanding refunds or account credits.

Not many abused this but enough did where I had to ask a fellow web host about the issue. He said it wasnt possible with any type hosting and I found that out later.

So I guess the point Im trying to make is, have an uptime guarantee, NEVER a 100%, even if you are running load balanced cloud/cluster or whatever. And try not to promise too much on SLA.

Its really hard to say what to offer on an SLA but now what I do is give small discount on following month depending on how bad the SLA was broke.

Id be interested in seeing some of your guy's SLAs. Since I got out of ddos protected hosting I have only once had to give discount for sla cause the clients ror app kept failing, which it turned out to be their fault in the end lol.
 
You have to have an uptime guarantee. How you setup your SLA is what can cause issues though.

It is advisable for hosts to have an Uptime Guarantee and SLA, but their is nothing saying a host has to have these.

I have seen hosts without these. Sometimes we dont wait for clients to contact us through SLA, if we find an issue that effected all accounts then depending on the issue we will inform clients of this and then give them a credit without them asking. This show to our clients we care and are proactively monitoring our servers.
 
It's not that hard to honor an uptime guarantee. Some hosts credit for one month, and some credit for just simply the downtime, which would probably be very little anyways. It would mean pennies to most customers - So why not choose that option instead of saying you'll credit a month and end up not abiding by it?
 
Personally I wouldn't offer an uptime guarantee if I don't actually provide the servers myself, unless you're generating enough income to offer discounted prices for the next months payment on the hosting, or unless you're willing to take a loss for a month. But if the provider offers uptime guarantee, I guess you'd be able to contact them to get some sort of discount on price for the next month too.

There'll always be an issue with offering an up time guarantee, it's just a risk most hosting providers are willing to take in order to generate more income.
 
SLA uptime's are an excellent selling point. You just have to be sure to use fine print and define exactly what is covered in the SLA.
 
Top