The standard way to measure uptime is to measure the percent of time that your application is available over a period of time. This is always a good idea to do, but I don’t think it is the best way to measure the availability of your application for many companies. I think a better primary way is to think about how confident you are, your coworkers, and customers are in the availably of your application. If everyone is confident that your products will be up pretty much all the time then I think that this is a better measure than any “nines”.

I admit that going on how you feel as a primary measurement may seem a bit silly or touchy-feely. But I think your feelings and intuition solves a lot of issues with measuring uptime naturally. When even trying to figure out what a good uptime target is in percent of uptime some things you have to consider are:

Do you include maintenance time? This is probably more of an SLA issue than it is a practical one. For some sites, being down during off hours really isn’t a big deal. As an example, imagine an application that serves grade schoolers in the United States — it really doesn’t matter if it is down in the middle of the night.

Financial cost of achieving uptime vs cost of downtime? Some companies can map this pretty easily — “we loose X dollars per 30 seconds of downtime”. You then figure out the man power and equipment cost of high availability and all you need is some basic math skills. However, lots of companies are not finance or commerce companies so this is more difficult to measure. Take stackoverflow.com for example. We do have advertisers and our careers product, but our most valuable factor in my opinion is our users and our communities. How do you measure this other than keeping close ties to your users and see how they feel?

Development speed vs uptime? It seems intuitive that a fast development cycle will lead to more interruptions than a more careful and tested process. This might not be true, faster release cycles often mean smaller changes and might in the end cause less problems. I am not qualified to answer this, but it is another factor in uptime. If we accept this as true (I don’t, personally), then you have to weigh the cost of being down vs new features. The way this cost is measured is going to be difficult.

What counts as being down? If the site is slow, is this the same as being down? For example, at a certain point you might lose a customer to another commerce site if it is taking forever to load the purchase page. This is related to how Google now includes latency of your site in their page rank system. If you have new serious bugs but the site is still up, is this basically the same as being down?

Recovery Time: I think one of the most important things in uptime is recovery time. The primary thought most people have is “How do I keep from going down?”. Things go down no matter what, Facebook and Google have had some uptime issues before and everyone will. However, how much downtime you have when you do go down is a matter of how fast you can recover. I think recovery speed is a better place to start than attempting to eliminate going down at all. Of course, you need to do both.

The CHI of uptime: So if you are going to capture availability in a number it probably needs to include the above as factors in your equation as well as other things I probably haven’t even thought of. I heard a talk by Dharmesh Shah at Business of Software 2010 about measuring his customer’s happiness by factoring in various measurable stats as a Customer Happiness Index (CHI). (You can read about this talk here). Trying to do this with uptime would need to capture the above issues and is a worthy goal. However, getting there is not a small goal either.

Getting a good feeling for how confident your customers and employees are about the availability of your application captures all of these issues naturally. Uptime stats have their value, but I think numbers and stats are often overrated.