Mike Brittain

These days, I find it’s a requirement for vendors to provide operational status pages on their services.  I say this because I know there are many companies who aren’t yet on-board.  Status pages give your customers an immediate answer to the question, “What’s going on with X site?” or “Why does Y service seem slow today?”

A status page could be as simple as some of the third-party magic eight balls out there like Down For Everyone Or Just Me.  But an effective status page will give more information than “yes” or “no”, and will communicate:

• Is the service or site down?
• How long has it been down?
• What is being done to fix it?
• When is the service expected to be back up?

Oh, and it probably warrants stating that you shouldn’t run these status pages on the same infrastructure that runs your site/service.  If your servers, network, etc. go out of service, you want to be sure that your customers can still reach your status page.

Let’s get on to some examples:

status.aws.amazon.com

Status page for Amazon’s Web Services which shows a separate status display for each of their infrastructure services.  There are RSS feeds available for each service allowing you to subscribe to monitor service outages.  One thing I like about this page is the “report an issue” link on the page, especially since it doesn’t require to to have your login credentials to quickly note an issue.

www.google.com/appsstatus

Similar in format to Amazon’s status page, this one also includes a running history of when the last issues occurred.

status.mosso.com and status.dreamhost.com

Status pages for Mosso and Dreamhost are fairly similar, they are both simple blogs.  Support techs post issues when they arise and follow up with time-stamped messages when services are diagnosed and fixed.

This is by no means an exhaustive list but I think it highlights a few good examples.  Why is this important?  As much as I hate to use the phrase “controlling the message,” it is really important that your customers know that you’re on top of things… especially when they are paying you.

Besides, in this day and age if you don’t tell your customers what’s going on, somebody else will, and you never know what they are going to say about you.

If you know of other good status pages, please feel free to add them to the comments below.

PC Magazine has an article on how mobile upgrades should be done (how Apple is getting it right).  This is something that has really ticked me off about other mobile operating systems, and why I think a lot of web application developers will tend to choose the iPhone as a platform of choice.  With Apple/iPhone, I can develop using (desktop) Safari as a test environment and open up the SDK to test mobile Safari with faith that my app is going to run well on any of the millions of iPhones in the wild.  That’s because the “wild” for iPhones is not all that wild.  It’s actually pretty standard.

Compare that to BlackBerry.  When someone asks me, “does One tsp. (my recipe app) work on a BlackBerry,” I have to say, “well, that depends.”  I’ve basically given BlackBerry users the stripped-down version of my mobile site because to support BlackBerry means supporting a whole range of BlackBerry web browsers that have been created over the last three years, or so.  If RIM upgraded their browsers on each of their mobile devices when new versions became available, then maybe we’d have a platform I could support.

If anyone has tips or suggestions for testing web applications across different versions of BlackBerry browsers, I would love to hear from you in the comments, or find me on twitter at @mikebrittain.