I’ve been hyper busy in the bat cave (aka the garden office) with end of year projects, Christmas parties and general shenanigans (who sounds like an Irish military commander). It’s times like this when it’s good to see another site straining under the weight of usage and the imaginative page showing that times are good, yet the server load isn’t. Many sites (the tr.im one is too the left) now put up fun pictures when there servers are taking the strain. These pictures let you down gently, but thoroughly (no slow response just no response) with a promise that coming back later will make everything alright.
We begin to rely on many web sites to provide instant responses to our every whim and when they don’t it’s somewhat of a shock. We never expect a Google application to break so when Gmail is sometimes down everyone gets all of a twitter on how it’s terrible, especially given for most people it’s a free service. This is the same when services such as Bing go down, TechCrunch said it well ‘Its one thing when startups, like Twitter, go down, which happens all the time. It’s another when a major search portal does it’.
In fact Twitter has one of the most recognisable site unavailable images on the interweb that of the fail whale. This charming graphic, which has often been seen by those people twittering via the website as the popularity of the site has grown, even has its own fan club (‘the fail whale fan club’) where you can buy mugs and t-shirts with the little whale plastered all over it. It’s amazing what a bit of imagination can do to endear people to what actually is a site failure (for whatever reason).
Under the hood
Now all these nice pages are doing are hiding the HTTP error codes that we have all seen emitted by our favourite application, that when not altered from its natural state tends to make their way to our web browsers which then renders it with the minimum amount of eye candy possible. Whilst it’s not only a sign of a poorly developed application to have raw error messages delivered back to the browser, it’s also bad to allow raw HTTP errors to fly around without even a little bit of window dressing.
This is a two stage process:
Firstly any web application or end point should emit the right codes when returning information, such as 200 for success and 404 if something isn’t found. REST services need to use HTTP codes appropriately to allow for the proper caching of information, through the use of conditional get, and the identification of bad requests for information. The RESTful web services bible gives an appendix dedicated to understanding which of the 41 HTTP codes that are needed (go on it’s an interesting read, honest guv!).
Secondly the web server needs to be configured to use a nicely formatted and informative page to return so as the user is nicely calmed and reassured as their application is going down in flames. In IIS you can configure the error pages that are sent by a whole server or an individual site through the admin pages and then craft the appropriate response that you wish your users to see.
There for by the grace..
Whilst it’s easy to mock a site that’s having scalability woes especially if it’s run by one of the major internet companies (the Bing error page wasn’t too comforting at first) it only takes a simple post by Slashdot to bring all but the best designed or resourced sites to their knees. Hopefully now if it’s one of your sites at least you’ll look good on your knees and your customers will remain calm. If your stuck for ideas Smashing Magazine has a list of cool 404 error pages that might give you some, even some off the wall ones such as my favourite: