There’s no ignoring server downtime. For better or worse, defects in your software can go unnoticed for weeks, perhaps being caught by only the most advanced users—but your application going down entirely: that will be noticed immediately, by all of your end users.

The solution is not to eliminate downtime (that’s just not possible to do 100%), but to reduce it as best as you can (this is what your IT team is for) and to communicate with your end users as well as you can on those infrequent occasions when it does happen. This is where hosted status pages come in.

Hosted Status Pages vs. Error Messages

Hosted status pages provide a clear communications channel for you to engage your customers about what they perceive to be a crisis (and perhaps rightly so), pulling some pressure off of your IT, Customer Support and general inquiry teams. While pressure/call volume represents an obstacle to efficiency for any team, it’s particularly important that your IT team has their hands free to work on resolving whatever has caused the issue—you don’t want to tie them up with communications about the issue they’re trying to resolve (especially when it amounts to little more than answering: “Are we there yet? Are we there yet? Are we there yet?”).

Earlier this month, I talked about why your customers deserve better than an error message when your application experiences downtime. These customers have come to rely upon your product to help them do their jobs well – which is great, that’s why you’re in business—but as a result, when that application goes down, it feels like the end of the world to them. The cost of downtime can be in the hundreds of thousands, so the sense of urgency they’re feeling must be treated seriously. How do you do that?

By integrating your application monitoring system (e.g. New Relic) with an application status page, your hosted status pages will provide up-to-the-minute updates on what progress your IT team is making. These hosted status pages are designed to be read and understood by both internal stakeholders (e.g. executive leadership) and external (e.g. end users), who possess little to no technical knowledge.

These stakeholders want to be kept “in the loop” as the situation is resolved, so in addition to providing a dashboard that non-technical staff can understand, your hosted status pages should be capable of sending out alerts in the end user’s preferred format, for instance email or text message.

Just like you can’t eliminate application downtime 100%, you can’t entirely eliminate disruptions from internal and external stakeholders looking for a status update – but an application status page is by far the best progress you can make towards 100%.