99.999% Hosting uptime SLAs do not matter to SaaS subscribers

Amazon S3 was down last week. A lot of blogs covered this, discussing the need for 99.999% uptime.  A lot of people invest their time improving hosting uptime. Even so, 5 minutes and 35 seconds downtime per year is very difficult to achieve.

The thing is, 99.999% hosting uptime does not matter at all to your SaaS subscribers. What matters is that they can login. If they cannot, then no matter what the reason, your SaaS system is down.

We must stop focusing on hosting uptime. Instead we need to start thinking about the total user experience. End to end uptime is the only thing that matters to SaaS subscribers.

Only end-to-end uptime counts

In a previous life I worked with IBM mainframes. What counted was response time to the user’s terminal. A similar issue applies to SaaS.

Your subscribers do not care about hosting uptime. If they cannot login then your system is down. Oh, and it is your fault! It could be a network issue. It could be a DNS issue. It does not matter. Whether or not your hosting is up, if your subscribers cannot login then it might as well be down.

It is easy to focus on hosting uptime. This is the wrong thing to do. Instead, try to see things as your subscribers do. This will make your life more complex, but it is a major benefit to your subscribers.

Out of (your) control

There are many moving parts between your SaaS host and your user’s desktop. A lot of things can (and will) go wrong. Your customers have an internal network. If their switch is down they are cut off from the Internet and cannot login to your SaaS application. For them, your system is down.

You have no control of most of these moving parts. They must all work for your subscribers to login. Do not try to control things you cannot. Instead, focus on giving your subscribers the best possible experience. Especially when something fails…

When anything, anywhere, fails you need to know about it right away. How will you know? Your subscribers need to know. How will you tell them?

Communicating In times of trouble

You have a real-time service dashboard to show the live status of your SaaS application. This is good, but it does not help your subscribers if they have a network problem and cannot reach your dashboard. If your subscribers cannot login, and they cannot reach your dashboard, then to them you have suffered a massive failure. Even though in reality their switch failed, your system is up and all your other subscribers are working OK.

Some might argue this is not your problem; they cannot be expected to handle everything that goes wrong. This might be true from a legal view of your SLA. What matters more, though, is how your subscribers view such faults.

If they cannot login then their trust in you and your system will drop. No matter what the real cause of the problem might be, you will pay for all problems with your trust.

Trust makes it your problem

Getting and keeping the trust of your customers is the most critical part of SaaS. This is why you need to think about all the things that could go wrong. Think about these things now, before they happen, and put a solution into place. The investment will more than pay for itself when faults occur and your subscribers know right away what has gone wrong.

You must ensure your subscribers always know the status of your systems. To do this you will need to provide status details using an independent “control path”. When the network fails you still need to keep your subscribers informed. This was the mistake that Amazon made with their S3 failure. They did not communicate with their subscribers.

There are a number of ways this can be done, and I will be looking at these in future articles here on ISV Survival. In the meantime, how do you manage all the moving parts between your subscribers and your SaaS system? Does your SLA take such problems into account?