Take the 2-minute tour ×

What are is considered best practice (layout, age of information, level of detail, etc.) for UX guidelines when creating system status and availability page(s)?

Below are links from major companies with the status of their services. The user experience on each site varies wildly from Apple's minimal approach to 37 signals product based approach to Cloud Flare's geographic approach.

I suspect that there would be two target audiences (which may affect UX) for the system status functionality; Support staff and end users.

share|improve this question
As usual, it depends. What is the target audience of your applications? nerds who want to know the sweaty details, or business people who only care about wether it works or not? –  Aadaam Sep 11 '12 at 1:30

1 Answer 1

up vote 2 down vote accepted

I'm looking at it from the customer point of view, but support staff will have a whole different set of requirements from that of the end user - in particular the ability to determine whether a specific customer or site has a problem and often support staff or engineers will have specific tools or software to help with that.

There's no real 'best practice' that encompasses what is really a quite broadly scoped question, at least certainly not in terms of layout, but there are some elements of information you should include.

Consider why visitors are coming to the system status page. Often it's because they have a problem and want to know where the blame might lie - your end or theirs.

So if a provider has multiple products or services which can have independent system issues whilst leaving others unaffected, then it makes sense to provider information on a 'per-service' level so that users can see whether their product is affected.

Or if a provider has geographically dispersed servers which can fail independently, then visitors should be able to determine from the status information whether the problem affects their particular location.

Sometimes a system issue can affect some, but not all customers, in which case a suitable message may by appropriate and would explain why they have a problem but their colleague in the next room may not.

Services can sometimes fail through no fault of the provider, but if the provider knows information that can help users, then the system status page is a good place to put it.

In terms of age of information given, a provider will want to give a generally positive spin on things and may want to balance the positives of showing that systems have been fine for the last week or so, against the negatives of showing that the frequency of system issues are so high that a weeks worth of information always includes one or two issues.

So in order to answer your own question you have to look at how the system may fail (all systems, by service, by location) and assess mean time between failure, and simply provide the information that a customer needs in order to determine whether the problem is likely to be yours or theirs.

Then if possible, back that up with a confidence boosting statistic showing that system issues hardly ever occur, so that next time they have a problem they are reasonably confident that the problem is more likely theirs rather than yours.

It boils down to management of the customer experience - being sensitive to a distressed customer's needs, and providing clarity of information, while also providing an overview of system reliability in order to set their expectations (and hopefully allay worries) for the future.

Above all, the information presented has to be honest - the system status page is not a marketing exercise. Having said that however, a consistently good record can be pointed at as a clear benefit.

share|improve this answer
BrightCove has a status page which has geographical split in the tabs; per service information in the rows; recent historical information in the columns, and simple information in each cell, but with more detail on hover. And the option to view even older historical information by using the right arrow in the right column header. –  Roger Attrill Sep 17 '12 at 10:05

Your Answer


