Website and Server Outage Discrepancies
WebWatchBot logs all successes and failures for post-mortem analysis in the event of an outage. First determine if the outage was recorded in WebWatchBot. If the outage was recorded as a failure, but an alert was not executed or sent, check the log file for specific error messages pertaining to the alert.
For all other outage discrepencies:
Scenario 1: A website is known to be down through manual tests of opening a browser window; however, WebWatchBot does not detect any failure and reports that the website is up, accepting connections, and returning positive results.
Scenario 2: A website is known to be up through manual tests of opening a browser window; however, WebWatchBot detects a failure and reports that the website is down, not accepting connections, and returning negative results.
(This is by no means a comprehensive list)
- DNS: WebWatchBot and the web server are on the same network and/or share the same DNS server and the remote computer browser and webs server are not on the same network and/or share the same DNS server. Essentially, WebWatchBot and the remote computer are taking different paths to the web server.
- Middleware caching: A middleware caching system is not providing fresh results, causing the appearance of being up or down.
- Load Balancing: The web server is part of a load balanced architecture - one or more web servers may be down, but the one WebWatchBot or the remote computer was assigned is not.
- Monitor with WebWatchBot outside the network to measure similar results as a computer not on the same network.
- Assign different DNS server addresses for the WebWatchBot server
- Bypass the middleware caching system and directly monitor the web server by using IP Address.
- Bypass load balancing and directly monitor the web server by using IP Addresses of each of the web servers.