This article sets guidelines for troubleshooting basic errors and addresses how to verify that a “false alert” is actually a genuine alert.
When users of Dotcom-Monitor system receive an Alert that a monitored Device (a website/network device/mail server etc.) has an Error they often proceed to “verify” the Error by simple operations like opening the webpage in their own browser or performing usual mailbox check. If visually everything looks good they may then mistakenly assume that the error is a “False Alert”. However, based on an extensive review of Dotcom-Monitor trouble-tickets that suggest a “False Alert” more often than not these “False Alerts” are actually genuine Alerts.
To determine the validity of an Alert and pinpoint the root cause of an Alert take the following steps in order:
- Enable Alert Silence for a time until you figure out reason for the Alert
- Check for recent server maintenance, or recent server and network hardware re-configurations, or updates to webpage content.
- Review Reports for details on Device state and Error details prior to creating trouble-tickets, specifically:
- Error Type and Description – helps to determine area of a search zone.
- Trace-routes – Intermediate network gear often causes delays and breaks that monitoring will detect.
- HTML Bodies – HTML may contain server error message with detailed descriptions.
- DNS traces – are very useful to pinpoint roots of the issue.
- In case of a “Time-out” error: Go to the settings for the the Task that is indicating an error and check the the “Maximum Connection Timeout” field for the value (example, “15 Seconds”) in that field. Network delays and server loads can significantly increase monitoring task execution time, so it will hit adjusted timeout value and trigger alerting, while monitored entity will still be operable.
If, after taking these steps, the reason for the Error remains unclear, or further assistance is needed – contact technical support via live chat or the trouble-ticket system: