Tag Archives: SLA

Monitoring Your Uptime – Free Tools


Server Uptime 448 Days & Counting
Server Uptime 448 Days & Counting

Clearly, one of the most important aspects of your website is how often it actually is a website. After all, if no one can access it, it’s not really a site but more of the idea of a site. Also, at times, it may be “up” but not fully functional… a groggy website that does not want to be bothered. Uptime, then, is a word used often by those conducting business online.

Uptime is also often phrased as “reliability” or “availability.” A site with high-availability has very little downtime because it is based on a system that is highly reliable. The same can be said of a 24-hour shoelaces store: if you need shoelaces at 3:30 AM, Every-time Lace Shop has got you covered. Plus, they won’t ask you any questions, such as, “Why are you here?” or, “Are you sure you need shoelaces?”

Hosting companies are highly concerned with the uptime their clients receive. They have to be, because it is one of the core concerns of anyone looking for a hosting solution: “What’s your guarantee for the maximum amount of downtime allowed?” Typically a hosting company will guarantee 99% uptime or 99.9% uptime or 99.99% uptime, possibly more – such as 200%, which is highly remarkable.

*** Pause for a commercial break: In our case, notably, we don’t allow any unscheduled downtime. For that reason, we guarantee 100% uptime in our Service Level Agreement (SLA) with all our clients. If we ever fall under that number, we will reimburse you and possibly (don’t count on it) give you a back rub. ***

In this two-part series, sponsored by Darrell’s Free Tool Shed International (a nonprofit tool-provisionary outfit), we will look at a number of different free tools to assist you in uptime-monitoring. These are tools you can use to ensure that you are getting the uptime you are guaranteed when you sign up for your hosting account.

We will use a couple different sources to broaden our perspective: Mashable and WPMU. Both sites provide 10-12 different options for free software you can use to monitor your uptime.

It’s a good idea to install all available software, create an intricate schedule to monitor your uptime-monitoring software, and then consider installing uptime-monitoring-software-monitoring software. Keep layering and layering until your uptime-monitoring matrix forms a layer cake of satisfaction that tastes good and is reasonably filling.

Free Online Uptime Monitoring Tools

Without further ado, here are several tools you can use to ensure you are getting the uptime you deserve. If you aren’t, phone your Congressman and bark into his voicemail (and whatever you do, don’t meow) … Also, e-mail your hosting company with details (including your barking experience).


Maximum websites monitored: 50

Monitoring frequency: 5 min.

Contact options: RSS, text, e-mail

The way this software works is it checks your header code. If there is ever an error, it digs deeper. If the more in-depth analysis suggests real problems, you are immediately notified by any of the methods listed above, or by airhorn.


Maximum websites monitored: 1

Monitoring frequency: Optional, 60 seconds minimum

Contact options: text (20 max./month), iPhone, e-mail

Pingdom is massive within this sector and primarily likes to make money, but it does offer a no-frills, unpaid option. Though it is limited to just one site, the phone app may make it worthwhile when you are walking, climbing trees, or jumping off your roof into a pile of Jell-O for a hilarious reality TV series.


Maximum websites monitored: 1

Monitoring frequency: 30 min.

Contact options: RSS, text, e-mail, instant message, paper airplane

This application is the dumbed-down version of Monitis, but it is easy to install and use. Rather than just notifying you of problems, the application creates statistics broken down into various time-frames. The stats populate immediately, for efficiency, or in slow-motion, for dramatic effect.


Maximum websites monitored: 1

Monitoring frequency: 60 min.

Contact options: text, e-mail, smoke signals

This site, so it says, is presently monitoring almost 2,000,000 sites. The company has gotten a bad rap for being aggressive with mass marketing campaigns. However, it allows numerous different people to be notified of downtime, and statistics – including CDC pandemic figures – are sent out to you each week.


Maximum websites monitored: 1

Monitoring frequency: 30 min.

Contact options: no notifications, except singing telegram

Uptrends, rather than being focused on letting you know when periods of downtime occur, is geared toward making your visitors aware how seamlessly your site delivers content. You can embed the code for its button, and it checks your site globally every half an hour. When anyone clicks the button, they receive information related to various time-frames, up to the previous year. (Previous eon is only available to Paleolithic users, most of whom are deceased.)

Conclusion & Continuation

So far, we have gotten a sense of several of the most high-profile and useful options out there for uptime monitoring. There are many more solutions available, and we will review some of those other major tools in the second and final part of this series. Then we will get a bite to eat and talk at length about my maritime marital problems, which are extensive and difficult to resolve, due to my chronic seasickness.

P.S. Considering our 100% uptime guarantee, you can’t go wrong with a shared, dedicated, or VPS solution from Superb.

By Kent Roberts

What is High-Availability? Part 2 – Problem-Solving


2 node High Availability Cluster network diagram
2 node High Availability Cluster network diagram (Photo credit: Wikipedia)

High-availability, as we learned in the last installment, has changed conceptually since the days of yesteryear and, for that matter, even near-year. It no longer just refers to the full-access, all-hours, 24/7/365 immediate-response policies of a man looking for love in all the wrong places and some of the right ones. It’s no longer about a man with a well-groomed mustache offering shoulder massages at closing time.

No, in the world of computers, high-availability is a completely different matter. Instead, it deals specifically with the uptime of a network. To properly understand uptime, we must consider that it is not merely about eliminating incidences of failure within a network (because, per Microsoft, failures are by their nature unpredictable). Rather, it is also about high rates of recovery so that the system is not affected for an extended period. With sound recovery methods, data delivery remains consistent. That’s why I carry a slide-rule with me to re-straighten my hair part if someone gives me a noogie.

To bolster our understanding of high-availability in this tripartite miniseries, we are assessing the perspectives of Microsoft, Oracle, and Linux Virtual Server. Today, looking specifically at the Oracle article, we will discuss several problem-solving methods.

While we consider high-availability, let’s put on our Easter bonnets and throw eggs at passing cars, focusing especially on the ones with their windows down. We’ll only be 13 once.

Availability: Quick Review

Oracle defines high-availability as “the ability of users to access a system without loss of service.” Really, that seems like a definition of availability. High-availability means that scenario is occurring almost all of the time. Even in a highly redundant system, there will always be occasional errors and glitches. Regardless, a system in which availability is optimized is highly reliable and does not experience very much downtime. A good example of this, according to the women of Austin, Texas, is my reproductive system.

Downtime can be thought of as scheduled and unscheduled. When it is unscheduled, the downtime is due to some type of systemic failure. When it is scheduled, users can be notified that upgrades or other system administration is being conducted (as with a hosting company and its clients, or with a website posting a notice to visitors). “Scheduled downtime typically occurs late at night, when traffic is light, all right, baby, all right,” crooned Barry Manilow.

High-Availability Problem Solving

Various types of problems can of course occur in a system. Types of common failures include those occurring within processors, nodes, and in various forms of media. Human error can also cause failures, as can monkey and camel error. Availability can maintain a high level by both focusing on localized problem-solving as well as methods of recovery in the event of a natural disaster, such as flooding or datacenter technician stampede.

Different sorts of best practices and technological solutions can help to make high-availability a reality. Redundancy, says Oracle, is the most important parameter to enhance availability: “High availability comes from redundant systems and components.” The same parameter applies to the man with the well-groomed mustache mentioned above, as he repeats the same psychosexual sales pitch over and over again, optimizing his systemic redundancy. Looking at solutions for localized high-availability in terms of redundancy splits potential fixes into active-active and active-passive groups.

  1. Active-active availability mechanisms: These mechanisms allow better scalability along with increased availability. Transmissions are duplicated in real time.
  2. Active-passive availability mechanisms: In this scenario, sometimes called cold failover clusters, one system instance is handling requests and the other one is sitting and pondering, running its finger through its hair, waiting patiently to be called into action. It chews gum and looks sullen. Clustering is used to integrate the two instances, with the clustering agent monitoring the active instance and switching over to the passive one as necessary.

Other Local High-Availability Solutions

Other safeguards should be in place to make sure your availability is as reliable as possible. Here are a few examples; we will proceed with more in the final part of this series:

Automatic restart & process death detection

You don’t want the system to continually restart multiple times in a relatively short window. Restarting can lead to additional failure. Technology should be in place to disallow repetitive, automated restarts. The same principle applies to excessively restarting one’s day. You should never get in and out of bed more than two dozen times before proceeding to breakfast.

Processes can die due to systemic errors. If processes are problematic, you do want a restart to be in place to give the process another chance. Don’t give it 10,000 chances though. Processes are greedy about grabbing all the chances.


Clustering means that the client computer (PC or other device accessing your system) will consider that part of your system to be one unit. This practice makes processing and administering the system easier. You can have processes clustered together and working on one server or on various servers, with the work divided evenly. It enhances redundancy by spreading out the process. Granola, similarly, is a highly redundant food. It should be eaten at all times when managing a server, even if you aren’t hungry.

Conclusion, Continuation & Poem

Availability and uptime are complex, but there are plenty of solutions out there to make sure that systems are as failsafe as possible. As stated above, I will continue to go over more of the safeguards that can maximize your availability in the final part of this series.

Here’s an eye-opening factoid that you may remember from the last post: we guarantee 100% uptime in our service level agreement (SLA), reimbursing our customers for any exceptions. You like the juice? We’ve got shared hosting, dedicated servers, and VPSs.

Now, finally, on a somber note, I’d like to close with a love poem to a dead process I once knew dearly … Well, maybe it’s not a love poem but a statement of redundancy-related anxiety. Anyway, it’s beautiful:

Process I can’t remember what you were doing

You’ve been dead now for years

Sometimes at night I can’t sleep

Because of my failure fears.

Come back to me, so we can share a club sandwich

While riding a tandem bicycle.

By Kent Roberts

Hosting Company Terms of Service (TOS), Part Three: Bandwidth & Utilization


front view of the cluster of Wikimedia servers...

Here it is, everyone … and, I know, the suspense has been maddening for all of us: Part Three, the final chapter in my series on web hosting terms of service (TOS). I will return to the conceptual admixture of Part One, capping off this trifecta with further thoughts not just on contracts, but on sentiments as well. As noted in that initial installment, the four places in which expectations are established between customer and client in hosting are in deals & offers, service level agreements (SLA’s), terms of service (TOS), and love letters sent by the company to its clients.

Let’s again briefly review what’s been covered to this point before moving forward:

  1. Introduction (company name, contact details, and an explanation of how parties will be identified in the document)
  2. Legal Compliance (an establishment of the notion that the company will not be held accountable for unlawful or rule-breaking behaviors by clients)
  3. Prohibited Usage (disallowance of adult content, plagiarism, software piracy, overages that infringe on others, interference with company tracking, etc.).

Today, we will move forward with additional provisions often included in the category of Prohibited Usage. Then we will move on to Bandwidth & Utilization. Again, these particular topics – both broad and specific – are not included in every hosting contract but allow an overview of stipulations and language you will typically see.

To create a distinction between the TOS and the love letter, the TOS is typically written in very specific legal language. The love letter your hosting company will send you is written in the language of the heart and sung in your best French accent (as all romantic literature should be), in a 3/4 time-signature, accompanied by maracas and sobbing.

Prohibited Usage (Continued)

As stated in Part Two, though prohibition is annoying for clients (no one wants to hear “no”), these guidelines are actually not all bad. Do you really want someone who is in the same hosting network that you are participating in hacking or high-malware industries such as pornography? If you answered maybe, well, that’s a better response than I get to most of my marriage proposal web hosting postcards: “Customer Survey: Will you marry me? (Check One.).”

The three standard sections left to cover are billing, mail, and customer support.


A hosting company will often specify that customers cannot use other people’s credit cards (what?!) or create a technological workaround to prevent the system from billing them correctly (double-what?!). Obviously, hosting companies like the purchase of their services to be an honest transaction. My love letters, similarly, are honest above all else. It’s with sincerity that I write, “I can’t stop thinking about your beautiful elbows.”


Typically provisions related to e-mail focus heavily on the prohibition of spam – technically called unsolicited commercial e-mail (UCE). Spam can be a difficult issue, because in some cases, companies send an initial e-mail asking for an “opt-in” from recipients. However, because people are so sick of unwanted e-mail, many will complain just based on the initial query e-mail.

Since mass-mailing is such a crucial part of online business, there are several things you can do to make sure you don’t become categorized as a spammer by your host:

  1. Implement double opt-in (good for marriage proposals as well).
  2. Include a note to recipients reminding them that they signed up for the list
  3. Make unsubscribing simple.

In addition to anti-spam provisions, the TOS may also state that mail will not remain on the hosting company’s servers longer than a specified time period, such as 90 days.


Terms of service will also often include a section requiring that a client maintain a respectful, non-harassing relationship with the company’s support staff.

Bandwidth & Utilization

This section details what is allowable with regards to the following:

  • bandwidth – the “stream” through which your Internet traffic runs
  • utilization – usage of server storage and other resources.


Here are a couple of standard provisions:

Non-Transference & Reselling

Typically a hosting company will state that the client cannot use its space on the server to store materials that are unrelated to the specific website(s) listed in its account with the host. Additionally, the customer must use the company’s authorized reseller program if they want to resell the space allotted to them to other clients: it’s not okay to set up a system oneself to resell pieces of the hosting package. Similarly, I notify clients in my love letters that I am hooked and will no longer be reselling pieces of my heart to the highest bidders at Plenty of Fish (not the dating site – a fish market in Sacramento).

Hot-linking can be a problem regarding this provision. You might want to set up tools to prevent that. Generally speaking, you want anyone who is using images from your site to download the image and upload it to their own server rather than simply linking to the image on your site. Linking to your image may not be malicious, but it uses your bandwidth to populate the image on the Web; for that reason, it’s typically considered a form of “bandwidth theft.”


That’s it for our explanation of terms of service. This series has really been a small sampling of the types of content that is included in these documents. However, you should now have a reasonable understanding of the typical contents, tone, and scope of the web hosting TOS. Finally, let’s go to a baseball game. I want to ask you a question on the Jumbotron.

by Kent Roberts and Richard Norwood

Hosting Company Terms of Service (TOS), Part One: Introduction & Legal Compliance


New Facebook Terms Allows Confiscating Furniture
New Facebook Terms Allows Confiscating Furniture (Photo credit: HubSpot)

Let’s talk terms of service, y’all. What’s the TOS? It’s a legal document you are signing when you create a web hosting account (typical for most online services, such as the increasingly popular Internet babysitter application).

To put this in context, this piece on the TOS is a follow-up to a two-part series on the service level agreement (SLA). To review, there are essentially four ways in which the relationship is established between a hosting company and a client:

  1. Sales copy – the informal offers & guarantees established on the homepage, in advertisements, etc.
  2. Service level agreement (SLA) – a brief explanation of the rights and responsibilities of the web host and of the client
  3. Terms of service (TOS) – a thorough explanation of the legal relationship between host and client
  4. Love letters/postcards – often a hosting company will send sweet nothings (such as elaborate epic poetry featuring dense, esoteric technical jargon) sealed with a kiss to their clients, via postal mail.


Obviously the sales copy is very punchy and inviting. The SLA is a little bit more balanced, with more focus on potential client violations that can result in termination of contracts, etc. The TOS is the most verbose and stringent, essentially CYA paperwork for the hosting company that does not usually come into play. Finally, the only rule of love notes is that there are no rules, baby.

Regardless of the fact that the TOS is complex, written in legalese, and doesn’t usually come into play, we will give you a basic sense of what’s in these standard industry contracts below. Perhaps it’s worth something. The content of our love letters to our clients, needless to say, is staggeringly valuable (as proven by the sale of our romantic postcard archives at a Sotheby’s auction in New York for $9.7 trillion to a Saudi Arabian Prince).


Let’s look at typical hosting TOS clauses. Obviously these differ from one company to another, but they’re fairly standardized. First, let’s look at the introduction. The introduction establishes the basic what and where, along with parameters for identification:

  1. Name of company & incorporation status
  2. How the document refers to you and to the company (such as “The Customer” & “The Company”); these broad terms simplify the language (well, a little) and allow the contract to apply to each individual customer
  3. Date that the contract was originally created and/or (if applicable) date it was last modified; you should be notified by the hosting company if any provisions in the terms of service change
  4. Physical address of the company – which you can of course also find in the return address on the love letter envelopes I’ve been sending you
  5. Contact details, which are typically an e-mail address and/or phone number – for clarification, disputes, etc.
  6. State laws referenced – Any legal contract falls under the laws of a specific state or territory, so the TOS will typically indicate what state that is
  7. I love you – The terms of service may or may not state explicitly, “Look… I feel this is a bit unprofessional, but I just have to say it… I love you. Please refer to article 6, section D, to find out how much I love you, and why.”

Legal Compliance

Man: “Will you marry me? Will you fulfill this contractual obligation? Will you legally comply?”

Woman: “Do I get to keep the ring if you become professionally unsuccessful?”

Man: “You are twisting my arm, but sure.”

Woman: “All right, then I am a strong maybe. I’ll text you later with my answer.”

The section on compliance with the law states that if you do anything that is illegal through your website or that does not agree with the terms of service, the hosting company is indemnified. Essentially this provision means that you are responsible if you are found to be breaking the rules/laws; the hosting company will not suffer any loss or other damages, financial or otherwise, as a result of your actions. This clause says, “I still love you, but I need you to go out and experience the full weight of the American judicial system by yourself, honey.”

An example, which might be stated explicitly, is if you are republishing copyrighted content. Come on, dude. Seriously? Who are you, Carlos Mencia (if so, hi, I love “your” “work”)? With intellectual property as an example, you can see why hosting companies need to protect themselves from potential lawsuits resulting from client behavior.

Probably you also can see that the terms of service document is essentially stating the obvious. Most people do not need to worry about it, unless they are the type of people who videotape their television set and then publish the video on YouTube (assuming their viewpoint of the TV is their intellectual property?).


So, we have made our initial ascent toward the summit of the mountain that is the terms of service. Fear ye not that it be a volcano! It is a humble, well-intentioned, snow-capped mountain of glorious beauty and wonder.

Again, today we covered two sections:

  1. the introduction (basically who the company is, where it’s located, how you and the company will be referenced in the document, etc.)
  2. legal compliance (making the hosting company unaccountable if you do anything illegal or that is outside of its codes of conduct within the TOS).

Okay, so two more parts to go in this series. By the way, I’m sorry I haven’t sent you a love letter recently. I’ve been very busy with my soap sculptures of poultry – which, as you know, I am passionate about.

by Kent Roberts and Richard Norwood

Web Hosting SLA, Part 2: Lack of SLA, Breaches & Examples

This is, as you can imagine based on the title, the second in a two-part series on the SLA. SLA, if you haven’t heard (where have you been, buddy?), is short for “service level agreement.” Hosting companies typically offer SLA’s to their clients, both to cover themselves legally and to let clients know what they can expect from the relationship. Hollywood actors also sometimes sign service level agreements, as with the 700-page, rosewater-scented document between Michael Douglas and Matt Damon for Behind the Candelabra.

Part 1 covered core components (specific expectations for client and host) and why the SLA is so important to the hosting service you choose. This article, Part 2, will get into what to do if there isn’t an SLA for a particular hosting company and what to do in the event of a breach. We will also look at two examples of service-level agreements:

  1. Ours (If you’ve got it, flaunt it, said J-Lo)
  2. Cornell University IT Department.

We will also review some of the stipulations set forth to ensure that Michael Douglas and Matt Damon had the most warm, open, mutually-satisfactory relationship throughout the filming of Candelabra, despite Damon’s raging amphetamine addiction.

What if There Isn’t an SLA?

It’s unusual for an SLA not to be present on a hosting company’s site. The reason SLA’s are so prevalent is because their purpose is fourfold:

  1. Clarity – Delineate the relationship between host and client so that there are no misunderstandings
  2. Efficiency – Pointing to the SLA can help to quickly and smoothly resolve disputes
  3. Client Protection – Your rights and responsibilities are stated explicitly
  4. Web Host Protection – Host rights and responsibilities are laid out as well (amounting to legal protection).


In other words, you are not the only one at risk without an SLA – the host is too. You might think that is okay because both parties are assuming risk. However, it leaves everything unnecessarily vague; better to spell everything out than to chance ending up in a heated debate – as when Douglas accused Damon of stealing his favorite purple bathrobe.

Breaches: Transparency & Monitoring

Transparency is crucial in the event of a breach. As Okta CSO David Baker states, “It’s important for the vendor to update customers throughout the disruption, whether an outage, a breach or a service interruption. Transparency is essential … to build trust that the problem is being addressed … and what work-around steps can be implemented.” Similarly to the content of an SLA, the behavior of a company following a disruption in service or other breach gives you a sense of professionalism of the organization.

You can determine if and when an SLA is being breached by using SLA management tools and uptime monitoring software, similar to the GPS chip that Michael Douglas had installed in Matt Damon’s right buttocks during filming of Behind the Candelabra.

Two Sample SLA’s

Superb Internet (um, that’s us)

We recently improved and expanded our SLA. Note that as described on our SLA summary page (and as is true with any legal contract), the official SLA form must be signed by both parties in order to go into effect. Here are three highlights:

  1. 100% uptime guarantee: any hour of downtime experienced results in a full one-day credit, double that for premium clients
  2. No loss of packets to Tier 1 backbone: every 1% of packets lost to the backbone results in a full one-day credit, double that for premium clients
  3. Two-hour parts replacement: every additional two hours for infrastructural repair results in a full one-day credit, double that for premium clients.

Cornell University

Below are specifications from an SLA issued by the Cornell University IT department. This SLA is interesting: it’s on a completely different end of the spectrum from our model at Superb because it’s extremely small-scale and housed at a nonprofit facility. Here are a few basics:

  1. Two-hour weekly maintenance: Rather than guaranteeing a certain percentage of uptime, Cornell IT notes that it will conduct maintenance for two hours each week. Beyond that, notice is provided prior to any scheduled downtime.
  2. Unforeseen circumstances: A list of circumstances that might create unexpected downtime is provided, including natural disasters, defective infrastructural components, and malicious attacks.


Michael Douglas accused Luciana Barroso, Matt Damon’s wife, of launching a malicious attack on Behind the Candelabra when she was seen embracing Damon on the set of the film. Douglas pulled some strings and had her arrested and sent to Gitmo.


As you can see, service level agreements are fairly straightforward. Make sure you look for them and understand what your rights are. Also understand what your responsibilities are, so you’re not caught off-guard. A hosting company never wants to be forced to terminate your contract for breach of the SLA.

I will get into terms of service (TOS) in a future article. Those are similar in many ways to the SLA, though much lengthier and thicker, allowing them to dive much more deeply into the subject.

Michael Douglas: “Come again?”

by Kent Roberts and Richard Norwood

Web Hosting SLA, Part 1: Why it Matters & Core Components

The SLA is something that many people look for when they are considering different hosting solutions. One might argue that it is, in fact, the first thing you want to check out. Why? Well, for one, because it is incredibly boring. Reading nauseatingly boring stuff is an important part of being a grown-up (sorry to alienate any of the six-year-olds reading this piece).

In addition to being awesomely boring, the SLA is good to read because it states clearly what your relationship is with a hosting company. It’s like a marriage contract. Without a marriage contract with your hosting company, you could end up like Matt Damon in Behind the Candelabra: unable to point to any real, solid specifications set forth by Michael Douglas. When your love for Douglas (your hosting company) evaporates, you will be stammering, surrounded by judgmental lawyers, bewildered and confused. “I’m sorry, Matt Damon,” the hosting company will say to you, “but you are going to have to leave. You’re a drug addict, and I, Michael Douglas, don’t want you here anymore.”

SLA in a Nutshell – A service level agreement (SLA) is a formal written agreement between two parties. It is a legal document, so if a company does not uphold its end of the arrangement, you can hold them liable. What the SLA allows is a certain set of expectations that is stated in hard language.

Let’s take a look at what the typical aspects of an SLA are, along with its general role in the hosting industry.

Typical Clauses within an SLA

First, keep in mind that an SLA does not necessarily take a particular form or contain particular types of information. It will be as broad or detailed as the hosting company wants it to be, much like Behind the Candelabra director Steven Soderbergh determines the level of specificity of Matt Damon’s doe-eyed dream sequence, in which he adoringly watches Michael Douglas ascend into the heavens to play his glittering piano for the angels.

That said, a service level agreement will typically include a number of standard pieces of information; this applies to any SLA (we will get into the SLA as it relates to hosting below). Here are the basics:

  • Different types of service that will be performed
  • Performance levels and exceptions (such as uptime percentage guarantees, which allow tiny percentages of downtime)
  • How the company will compensate or otherwise account for service disruptions and other failures to adequately deliver on SLA specifications
  • Types of support available for clients
  • Basic expectations for clients
  • Conflict resolution (whether arbitration will initially be used in lieu of court battles, etc.)
  • How services are ended.

The SLA may also contain a clause that guarantees Matt Damon a lock of Michael Douglas’s hair in perpetuity.

Guarantees, Terms of Service (TOS), & SLA

Guarantees are typically presented in three different places on a hosting company’s website:

1. Marketing language (such as sales copy on the homepage)

  • Money-back guarantees
  • Uptime guarantees

2. SLA

3. Terms of service (TOS)

The latter two are of course much more formal and provide more thoroughly defined information. Actually, the SLA is kind of a midway point between the sales copy and terms of service. It’s a quick, though careful, statement of expectations; and it’s “meant to be read.” The terms of service, on the other hand, is that 10-page document that most people never read.

Fun fact: Though Michael Douglas could not give Matt Damon a prenuptial agreement, he did give him a pre-snuggle agreement. It was 700 pages long and sprinkled with rose water.

SLA’s in Web Hosting

In the web hosting space, the following parameters are often seen in the service level agreement:

  1. How you will be compensated if the uptime guarantee is not achieved
  2. What type of support is offered for various service packages (dedicated versus virtual hosting, for example)
  3. What’s required to cancel service
  4. What kind of content (such as pornographic) and file types are unacceptable.

Either the web host or the client can point to the SLA to establish how the other party did not meet stated expectations. The Matt Damon/Michael Douglas Behind the Candelabra SLA, for instance, guarantees 30 minutes of pillow talk following any “roughhousing.”

Client Protections

These are some standard protections you might see in an SLA, though this information may be in the terms of service instead:

  1. Account termination processes, cancellation notices, & rights to refunds
  2. The maximum amounts of resources you can use
  3. Billing information
  4. Basic agreements you are making when you sign up for an account.

The SLA between Matt Damon and Michael Douglas also stipulates that what happens behind the candelabra … stays behind the candelabra … except for movie rights.


That’s the gist of what to expect in an SLA. The main point here is: read it (six-year-olds, do your best). It’s typically pretty quick. I will continue this discussion in a second piece, in which I will cover lack of an SLA, what to do in the event of a breach, and provisions within our SLA and that of Cornell University’s IT department.

Hey, what’s that behind the candelabra? It looks kind of like a candle.

by Kent Roberts and Richard Norwood