Getting to the Core of Website Uptime – Part 1

Website Uptime isn’t a Condition, it’s a Calculation

Central to service level agreement (SLA) reports is the concept of  website “uptime.” However, what exactly is uptime? Website uptime, in the recent past was often narrowly defined as the working vs. non-working condition of a web server, ie web server uptime. (For a free test of web server uptime click here.) More recently, we have worked with many organizations that are carefully defining the details of website uptime vs. downtime, by taking into account variables like network uptime, server uptime, web application uptime, or website uptime, has become critical. Why?

Defining Uptime for the Uptime Calculation

The reason is website uptime, as part of SLA reports, impacts revenues. Therefore, the up vs. down condition of a server is not enough. Detailed uptime calculations that take into account server uptime, network uptime, website uptime, or web application performance uptime and other uptime variables are needed. When added to an SLA report provided by monitoring, these variables provide a more complete and realistic picture of website uptime vs. downtime. In order to set up an uptime calculation that makes sense, its a good idea to think through your website uptime profile.

What is your Uptime Profile?

To get started on a specific uptime profile, first consider the purpose of your website. What do you really care about? For example, if you don’t care that a third-party ad server doesn’t serve an ad to your website is your website down if the ad isn’t served? If a variable isn’t important to your uptime you’ll want to determine if you can remove that variable from the uptime calculation.

Also, consider the various components of your website – server, domain name server, webpage, network, applications, third party hosted page elements, etc…What components do you have control over? What components do you have insight into regarding their uptime vs downtime? For example, if you don’t have insight into the uptime of a web application on a website, how are you going to include the web application as part of the website’s uptime report? Its important to ensure you know what your uptime calculation includes and excludes.

Then, consider how your downtime is defined. Below are a few ideas to get you started:

• If you have scheduled maintenance on your web server every Sunday evening, is your website down?
• If your response time data indicates that your web application performance is slow, but a video play-back of the web app performance actually shows an acceptable user experience, is your web app down?
• If your Chicago-based web server cannot be reached from Orlando, FL (but is available from the rest of the USA) because the backbone provider Time Warner is having an issue in Orlando, is your website down?
• If a third-party hosted element (say a chat widget) is experiencing a server error, but the rest of your website is available, is your website down?
• If your website is not available from anywhere in the world –due to a server hiccup, which last 5 seconds – is your website down?
• If your retail website’s shopping cart is working, but your About Us page is not, is your website down? What is your shopping cart is down and About Us page is up?
• If one DNS servers is down but three others are working, so 25% of clients cannot get access to site after the cached TTL expires, is this a downtime condition?
• If one of three web servers in a web farm is down and web page response time increases by 25% (slower page load time) is this downtime?

(NOTE: If this downtime meant you needed to wake up on a Sunday at 2 am to fix the issue, how would your answers change? If your website monitoring solution provided detailed diagnostics that pinpointed the error, so that you could repair the situation 10x as fast, would your answers change again?)