SLA. is an acronym for service level agreement. Basically it is an agreement between a client and a provider that states that the provider will gaurentee a certian level of servce.  That being said the term can usually be very misleading.  It’s that time of year again and compnies are reviewing the “final, final, revised, final”, version of this years budget. The people in charge of picking hosting and internet providerrs and such are trying to get in their last minuet picks before that new contract is signed, and I am getting questions from small and large clients alike, asking me to decphier some of the SLAs being offered by both hosting compinies and internet providers. I thought I would take the time to provide a quick overview of how to do this and to debunk a few of the myths out there about SLAs.

 

 

 

What they give you:

 

SLAs are more like a coupon for nagging then they are an actual agreement. Typically SLAs are written so you get a discount or a service if the SLA isn’t met. They normally do not let you off the hook from a contract, and I have never seen one that promises to give you money back (doesn’t mean they don’t exist). It does however give you a good base line of what to expect, service wise, from your provider, and a good point to start being dissatisfied if something goes wrong. Again, you want to think of a SLA as a point to start harassing the sales/complaint department, rather then the deal breaker.

 

What they cover:

 

For us, SLAs cover mostly server uptime, service availability, and Internet availability. For example HostGator states, on it’s home page, “99.9% Uptime Guarantee”. ISPs for commercial use usually prove an SLA of bandwidth pipe (i.e. so slower then 5mbps). Server companies like Rapid systems provide SLAs on server availability (100% Network Uptime SLA)

 

What they don’t cover:

 

Now here’s the fun part. While the SLAs cover some things, they are in truth pretty narrow. For example, the HostGator example above measures their uptime as “The uptime of the server is defined as the reported uptime from the operating system and the Apache Web Server which may differ from the uptime reported by other individual services. (refrence)“. Basically they decided rather their hosting is up or not, if it’s not then you get a credit (on next month) not your money back. They do not let you use your own tools to do the measurement.

 

Server beach (sla details here) have a much more detailed SLA, but it is also restricted in several ways.  Timers for the hardware SLA start “within one hour following PEER 1’s receipt of Customer’s trouble ticket concerning the hardware issue and PEER 1’s identification of the failed hardware”. It also states, “The Replacement Guarantee does not include the time required to rebuild a RAID array or the reload of the operating systems and applications or changes to hardware during Maintenance, as defined below.” There are also other statements that state “PEER 1 guarantees that the PEER 1 network will be available 100% of the time, excluding Maintenance, as defined below.” And goes on to define maintenance as “ …Scheduled Maintenance or Emergency Maintenance.”

 

Again we see the scope is very narrow and only overs a very few things. It also shows that 100% uptime is not really 100%.

 

What to look for:

 

That does not mean that the SLAs are pointless. It just means you need to read them carefully and know what they are saying. The two main things to look for is how the percentage is measured (from Serverbeach: “….100% of the time in a given month”) and make sure that the time frame is normal. A daily SLA is best, but monthly is more common.

 

Also keep an out out for the excluding circumstances. Like power outages and hardware failures. Again to use ServerBeach as an example there replacement SLA is 1 hour after they figure out the problem. It could take them 6 months to figure out the issue (using an extreme example here).

 

Look for SLAs that measure simple things. And get clear definitions of words like downtime, uptime, and service. Also, if your going to look at SLAs, try to get one that give your a quality of service (like a certain speed on an internet connection) over one that just guarantees existence (your Internet will work).

 

Keep a close eye on the “what to do when stuff goes wrong” part of the SLA. If there’s an automated system for handling SLA complaints that shows that there is a large number of SLA problems being submitted (though they may not be valid). On the other hand, if there is no resolution section, it shows that the company is not serious about it’s SLA. I like to choose one that is a “call Fred, or email Lucy” situation.  At least I know that I will have someone to complain at when something goes wrong.

 

The Best SLA:

 

The best SLA I have ever seen is this one (from SliceHost);

 

 

 

Do you offer an SLA?

 

Not for Slices and here’s why: most hosting SLA agreements are just plain silly. They promise things like 99.9% uptime, but downtime excludes: scheduled maintenance, network outages, hardware failures and software trouble. Well what exactly is left to cause downtime? Here’s our SLA: we’ll do our best to keep your machines running smoothly for as long as possible and get them up ASAP should something go wrong.

 

 

 

 

 

I think that is the best SLA I have ever seen and Slice host has never let me down.

Coteyr.net Programming LLC. is about one thing. Getting your project done the way you like it. Using Agile development and management techniques, we are able to get even the most complex projects done in a short time frame and on a modest budget.

Feel free to contact me via any of the methods below. My normal hours are 10am to 10pm Eastern Standard Time. In case of emergency I am available 24/7.

Email: coteyr@coteyr.net
Phone: (813) 421-4338
GTalk: coteyr@coteyr.net
Skype: coteyr
Guru: Profile