Alert escalation
Also known as ordered alerting, the ability to escalate alerts makes it easy to share problem resolution with administrators in various levels of your organization.
The Alert Range parameter is located in the Availability section of each configured action. This parameter determines exactly which failure notifications an action will handle.
How to notify a supervisor after the sixth alert
You can create and configure an alert to send notifications when very specific failure instances occur.
For example, a supervisor asks to be informed when a resource does not recover after the sixth failure, but may not be interested in prior failures because the supervisor delegates IT staff to handle such problems. When the supervisor is alerted, the problem could be detrimental to business operations or the IT staff did not respond to the alerts in a timely manner.
To address this situation, configure the following settings:
-
In System Settings, scroll down to Optional Defaults and set the Maximum Alerts To Send setting so the monitor triggers six or more alerts when a failure occurs. This setting stores the maximum number of alerts to generate before assigning the monitor to a Lost operational state. The monitor must belong to a notification alert to generate an alert.
- Set the Alert Range setting for the IT staff to 1-5 so they receive the first five alerts. Configure the alerts so they are received by two or three IT staff members.
- Set the Alert Range setting for the supervisor to 6 so this individual receives the sixth alert.
By default, the Alert Range parameter is set to 1-, indicating either of the following:
- Send all alerts
- Send 1 through to n as determined by the monitor's Maximum Alerts to Send parameter
Timing considerations
When you configure your test duration setting, be sure to consider time delays required for a resource to process.
For example, in the System Settings under Optional Defaults, if you set the Maximum Test Duration setting for a POP3 User Experience monitor to 60 seconds, the setting may generate a premature alert. For example, the mail server could take up to 15 minutes to move an incoming message from the inbound queue to the mailbox during peak times. This example illustrates how important timing considerations can be to alert escalations.
When you create a reboot server alert to follow a restart service alert, consider the time required to restart the service and for ipMonitor to confirm the recovery. If your selected time period is too short, the computer may reboot without cause.
The potential delay in restarting the service must be accounted for as part of the testing interval for the Delays Between Tests While: Down setting in the monitor configuration settings.