Click here to Skip to main content
13,556,208 members
Click here to Skip to main content
Add your own
alternative version


14 bookmarked
Posted 19 Jul 2004

Automatially Recover from Web Server Failures

, 19 Jul 2004
Rate this:
Please Sign up or sign in to vote.
This article addresses the dreaded "Page Cannot be Displayed" message, and explains how to use HTML frames and JavaScript to catch web server failures and automatically reconnect when the server comes back on line.

Sample Image - ServerDown.jpg


This article addresses the dreaded "Page Cannot be Displayed" message, and explains how to use HTML frames and JavaScript to catch web server failures and automatically reconnect when the server comes back on line. It's best suited for intranet applications that auto-refresh themselves and don't necessarily have users working at them all the time (like a manufacturing facility).


I write intranet applications that run on screens throughout the company and display up-to-date statistics. Most of the time, there is not a user standing at the screen clicking a "refresh" button; the pages automatically refresh themselves using JavaScript. This works great until the web server goes down either for scheduled downtime or for a failure. This results in a "Page Cannot be Displayed" message and the page no longer tries to refresh itself. In the past, this meant going to each computer and reloading the web page--a simple task, but not when you have hundreds of them!

Using the code

This technique requires two HTML files that handle the error trapping and recovery. The demo VB.NET project includes these files along with Home.aspx as an example auto-refreshing application. The architecture of the setup uses an HTML FRAMESET as diagrammed below:

Sample image

The client uses the URL http://MyServer/MainFrame.html, which contains the FRAMESET, which contains two FRAMEs: Monitor.html and Home.aspx. The frames are setup so that Monitor.html is initially hidden and Home.aspx takes up the entire client area:

<FRAMESET id="FrameSet" 



   <FRAME SRC="Monitor.html">
   <FRAME SRC="Home.aspx">

The main application takes care of refreshing itself. The magic is in the Monitor.html page, which checks the innerHTML of the other frame (Home.aspx) looking for tale-tell signs of an error. It does simple string matching to look for things like "HTTP 404" or "The page might be temporarily unavailable". It is up to the developer to come up with the necessary criteria.

 function frameHasError() {
     try {
        var frameDoc= window.parent.frames(1).document;
        HTML= frameDoc.body.innerHTML;
        if (findText(HTML,"HTTP 404")) return true; 
        if (findText(HTML,"The page might be temporarily unavailable."))
          return true;
        if (findText(HTML,"Cannot find server or DNS Error")) 
          return true; 

        // TODO: Add additional search criteria
        lastURL= window.parent.frames(1).location.href;
     catch(e) {
            return true;
     return false;

Once this function detects an error, it takes over by resizing the FRAMESET so that it now takes up the entire screen with a user-friendly message explaining that the server is not available. It then goes into a refresh loop (in this case, every 5 seconds) refreshing the application page (Home.aspx) and checking for errors. If none are found, the server must be back up. It resets the parent FRAMESET back to its original state (with Monitor.html hidden).

function checkStatus() {
    try {
        if (frameHasError()) {
        else {
    catch(e) {

function setFrameSize(size) {
    var frameset=window.parent.document.getElementById("FrameSet");
    if (frameset) {
        frameset.rows=size + ",*";

An additional recovery method (not covered here) is to have a .NET <customErrors> redirect page setup in the web.config that points to an HTML page that contains similar logic. This way, you not only catch server failures but unhandled exceptions as well.

Points of Interest

You can alter the refresh times and monitor times by editing the JavaScript in Monitor.html. This technique can be heavy on the network, that's why I only suggest it for intranet applications that need to auto-refresh and recover from server failures.


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Barry Etter
Web Developer
United States United States
No Biography provided

You may also be interested in...


Comments and Discussions

GeneralGreat work! Pin
Tomas Danek27-Aug-04 10:03
memberTomas Danek27-Aug-04 10:03 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.180515.1 | Last Updated 20 Jul 2004
Article Copyright 2004 by Barry Etter
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid