Risk Mitigation and the True Cost of Website Downtime
Most businesses don’t think twice about the necessity to carry the insurance policies to protect against various forms of loss. Errors & Omissions, Workers’ Comp, Liability… managing downside risk of unforeseen losses and limiting potential damage is a standard cost of doing business.
But rarely do business owners go into a hosting scenario with cost of website downtime in mind. If your website is a critical component of your business, depending on how essential it is to your business’ function you should be thinking about the criticality of uptime and methods to insure this similar to how you insure against other forms of loss. There are primarily three ways in which downtime negatively impacts most businesses:
1. Opportunity and Productivity Cost
Perhaps the most serious potential effect of site downtime is the cost of lost opportunity. For an eCommerce site, that could mean lost sales. For an educational institution or SMB, it could mean lost registrations or missing out on new leads. Lost productivity is also a major problem – when a website goes down, countless hours can be spent resolving the problem or managing secondary issues. Basically what work can employees, visitors, customers not accomplish while your site is down?
2. Damage To Brand Perception
Of equal concern, but more subjective, is the potential damage to your reputation. You only ever get one chance to make a first impression. If your site is down when a new prospect arrives that sets an immediate red flag. Even if it’s a simple transient issue that takes your site down for a few minutes, from that visitor’s perspective, you’re down.
3. Damage To SEO
Depending upon the length and frequency of your site’s downtime, it’s possible that your ranking in the SERPs could be affected. A single event of short duration will likely have minimal long-term effects (although your ranking could be displaced for several hours or more). Extended or repeated downtime will probably give Google reason enough to replace your site with one that is more reliable.
It’s important to note that we’re talking about actual downtime here. Slowness is a separate issue of equal importance and we recently published a two articles on that exact topic which discussed how to identify slow pages and diagnose the cause of slow pages. As far as Google’s official stance on slowness, the former head of Webspam, had this to say:
You don’t get a boost for having a fast site. Sites that are outliers in terms of being slow will rank lower. All other things being equal, a site that’s too slow will rank lower. – Matt Cutts
Why You Should Quantify The Risk and Impact of Downtime
Successful risk mitigation requires that you first understand the risk. Only then can you can take the appropriate steps to reduce or eliminate the potential effects.
In regards to website downtime, you are faced with the option of risk acceptance or risk limitation. Neither risk avoidance nor transference is possible.
By understanding the costs associated with downtime, you are in a better position to make educated decisions. Meaning, you could choose to reduce the risk of downtime or accept it. But which one is the right choice?
If your website is not responsible for generating leads and revenue or maintaining brand perception, then acceptance might be an appropriate strategy. There is no sense insuring against a risk that does not exist.
If your website plays a key role in your business, risk limitation is usually the appropriate strategy. Successful risk limitation involves making sure the cost of limitation does not exceed the actual risk itself. For example, maintaining an insurance policy with annual premiums that exceed the potential cost of downtime would not make financial sense.
Calculating The Transactional Risk of Downtime
The risk of damage to brand perception is difficult to quantify and the effects of being downgraded in the SERPs is equally challenging to measure. Although not a perfect formula, calculating the cost of lost opportunity is possible providing you have adequate historical data.
Let’s take a closer look at how you might run your calculations. The formula we’re going to use is:
Risk = Probability of Downtime x Potential Impact of Downtime
Using historical data, we’ll calculate the approximate cost of downtime per hour. The ease of this calculation will vary depending upon the type of website you are running (more on this later). For example in 2013 Amazon experienced an outage that cost the retailer an estimated $1.86 million per hour based upon their previous quarter’s revenue. Obviously I’m not suggesting that the impact of your downtime will rival that of Amazons, but it’s the calculation here that’s relevant.
First calculate the average quarterly revenue and then divide by the number of hours in 90 days (2160). This will give you an approximate revenue per hour figure.
Measuring Downtime Probability
Without too much difficulty, you can calculate the probability of server downtime. The first place to look is your historical server logs. Alternatively, you could ask for historical aggregate figures for downtime across a sampling of your hosts customers. Free and paid uptime monitoring services are also available such as Pingdom or UptimeRobot. How exactly do these uptime figures translate?
Some examples of uptime percentages and the corresponding downtime results are:
- 98% Uptime over 30 days = 29 Days, 9 Hours, 36 Minutes – Downtime is 14 Hours 24 Min.
- 99% Uptime over 30 days = 29 Days, 16 Hours, 48 Minutes – Downtime is 7 Hours 12 Min.
- 99.5% Uptime over 30 days = 29 Days, 20 Hours, 24 Minutes – Downtime is 3 Hours 36 Min.
- 99.9% Uptime over 30 days = 29 Days, 23 Hours, 16 Minutes – Downtime is 0 Hours 43 Min.
**NOTE: at the time of publish of this article a random sampling of Pagely sites averaged over 6mos has 5 9’s of historical uptime for a total of 3min of downtime in the past 6mos. You can always see the latest Pagely uptime stats (bottom of page).
ENJOYING THIS POST?
Pagely has a number of managed hosting solutions to help big brands scale WordPress.
Calculating The Risk
Now that you know the impact of your downtime as well as the probability, you can calculate the potential risk.
Let’s calculate based upon an average revenue of $250,000 /quarter.
$250,000 / 2160 hours = $115/hour of downtime.
At 98% uptime, you would be looking at approximately $1644 in potential lost revenue or $115 x 14.3 hours.
These calculations only address the lost transaction cost of downtime. If your business is such that a first impression is critical you really need to factor in the lost LTV of that customer to quantify the total risk here. There are also variables of seasonal & time-of-day spikes so this is just back of the napkin math in the event of a random outage. Unfortunately downtime is usually precipitated by conditions of extreme load – precisely the time when the cost of being down is greatest ?
With the LTV concept in mind let’s take an example scenario to dig into this a bit with a SaaS service:
Cost of Downtime for A SaaS Website
Let’s say a SaaS service signs up 18 customers/day during business hours between 8am-5pm and has a customer acquisition cost (CAC) of $50/customer. Those customers stay on average for 6mos paying $100/mo for a total LTV of $600ea. If we’re talking strictly about the marketing website being down (ie. your SaaS application isn’t affected) then the cost for an hour of downtime during business hours is both the wasted CAC of acquiring the visitor as well as the lost LTV of that customer. In a 9hr window if you’re down for an hour you just lost the LTV revenue and CAC on two customers for a total of 2*(50+600) = $1,300.
Now that you have some idea of how to calculate the cost of downtime to your organization, you can begin to do the math on how much it makes sense to spend to insure against that downtime. In Part II of this series on downtime we go over how you can calculate your optimal spend to get the most from your site without diminishing returns of overpaying for downtime insurance you don’t need.
Original image credit: Sebastian Vandrey @ Flickr