Alert Policies (Deprecated)

Alert policies are a great way to streamline incident management workflow. You can easily manage the content and recipients of an alert and the life cycle of both alerts and their notifications using Alert Policies.

There are 5 different policies that are provided above within the outline. Within the alert creation and notifications flow, at most one policy from each type can be applied for a single alert (if Continue to Next Policy option is not enabled). When an alert is getting created, only the first policy that satisfies both alert content-based conditions and time restrictions from the top will be applied. In other words, order matters.

You can define several policies that will be operative for different kinds of alerts; to be able to control alerts and their notifications inclusively. For example, you can define a delay policy to delay notifications for all or some of your alerts based on the policy's condition set; and this way, you will be able to delay notifications for alerts from different integrations at once.

You can create and manage alert policies using Policies page.

Modify Policy

Modify policies can intervene and modify any alert while it is being created. You can change or append to alert properties like message, description; even change the recipients of the alert before it's created.

Modify policies have an option to process more than one policy. If Continue to next policy option is enabled, the next policy will be processed in modify alert policy list. This chain execution will stop at the first policy which has disabled this option.

📘

Modify Policies are only available within Enterprise plan.

Notification Policy

Notification policies apply to notifications of alert actions, like new alert creation, acknowledge notifications, etc. You can apply different operations to all your alert notifications, using Notify policy. As for every alert policy, you can specify which type of alerts the policy will apply to.

📘

Notification Policies are only available within Enterprise plan*

Suppress sending notifications

This option will prevent all notifications for any alert that the policy is applied. In other words, when an alert is matched with a notification policy that has a suppress option, no one will be notified for alert creation or any alert action.

Delay notifications

This option will delay alert notifications for a specified fixed time or until the desired day of week and hour minute time. You can use this policy as a maintenance window to suspend notifications of newly created alerts for a time. Please note that if the alert is acknowledged or closed before the delay time expires, notifications will not be sent.

One of the For and Until options have to be selected if you are delaying notifications. If you select For xxx minutes option, alert notifications will be delayed for the specified fixed time. If you select Until option, the notifications will be delayed according to the following patterns for each option:

• First HH:MM Alert notifications will be delayed until the first specified HH:MM based time on any day.
• Next Weekday at HH:MM Alert notifications will be delayed until the first specified HH:MM based time on first weekday (Monday, Tuesday, Wednesday, Thursday, Friday).
• Next specified day at HH:MM Alert notifications will be delayed until the first specified day and hour-minute based time. For example, if the delay until option is Next Monday 08:00 and the alert is created on Feb 29, Monday 08:30, the notifications for the alert will be delayed until March 7, Monday 08:00. However, if the alert is created on Feb 28, Sunday, the notifications for the alert will be delayed until Feb 29, Monday 08:00.

Deduplication Correlation

When an alert is matched with a notification policy that has a deduplication condition, the notification flow of the alert will not start unless the deduplication condition of the matched policy is satisfied. As soon as the alert satisfies the deduplication condition, notification flow will be started.

Deduplication correlation can be configured in two different ways:

• You can delay notifications unless the deduplication count equals a particular value.
• You can delay notifications unless the occurrence rate exceeds the threshold that you specified. Please note: that the alert creation itself is also counted as an occurrence.

The following is an example scenario that is covered within the alert activity log:

Auto Restart-Notifications Policy

Configuring Auto Restart-Notifications Policies is a great way to ensure that no problem is missed or forgotten without being resolved. If an alert matches an auto restart notifications policy, the notification flow of the alert will restart when the specified time of the policy passes after the alert creation time (Even if someone acknowledges the alert). When an auto restart-notifications policy hits, the current notification flow will be discarded and restarted regardless of the current recipient or escalation states. In other words, the behavior will be the same as an executed UnAcknowledge Alerts on the alert. If the alert gets closed in the mean time, no action will be taken.

📘

Auto Restart-Notifications Policies are only available within Enterprise plan.

When an auto restart-notifications policy hits, the following policies are also re-triggered and their time states get refreshed:

• Auto Close
• Auto Restart-Notifications
• Notification Policies with Delay or Suppress Options

Therefore, the auto restart-notifications policy is scheduled to hit after the specified time again, if the specified upper limit is not reached yet. Please note: you can configure an auto restart-notifications policy to repeat 20 times at most for a single alert.

Auto-Close Policy

Auto-close policies can ensure all your alerts to be get closed eventually. The alerts that match an auto close policy will be closed automatically a specified time after their last occurrence. In other words, if an alert becomes de-duplicated, auto-closing the alert will be postponed for the time that is specified in the the policy. If the alert gets closed in the mean time, no action will be taken.

📘

Auto-Close Policies are only available within Standard and Enterprise plans.

You can see the screen-shots below for an example auto-close policy setup and action.

Checking Alert Logs

You can see which alert policies were applied to an alert easily through the alert's logs.

Migration Guide for Deprecated Re-Notification Policies

Re-Notify options for notification policies are deprecated as of the date of August 22, 2016 and organizations that have a notification policy with a re-notify option (either Renotify if not acknowledged or Renotify if not closed) are needed to migrate to an alternative configuration until November 25, 2016.

Why These Options Are Deprecated?

• To provide a simpler way to build your incident management flow. You had to configure a global notification policy with re-notify options to ensure that no problem is missed, and providing different options for different teams or escalations were difficult. Besides, because the order matters and only the first-matched notification policy is being used for a created alert, configuring when and who should be re-notified was a bit challenging, especially if you also need other notification policy options.
• To reduce the number of configurations that you have to deal with. According to a lot of feedback from our customers, being have to deal with another configuration just to ensure that no problem is missed was a difficulty.
• To prevent unnecessary spamming to responders. Configuring a re-notify option so that it unnecessarily spams the alert responders / recipients by mistake was as easy as pie. At the end of the day, alert fatigue can be deadly!
• To simplify notification settings for responders. Users had to configure a separate notification rule for Re-Notified Alerts to be able to receive notifications from re-notify policies, and this requirement was easy to escape the attention for users.

Okay, What Are My Alternatives Then?

Escalations

Escalations are even more powerful now so that the state of an alert and its recipients are reverted back while an escalation is repeating to ensure that its recipients are notified on the next turn. You can easily setup your escalations to repeat a specified time after its last rule is processed. Configuring different needs for different teams/escalations will be easier now!

You can refer Escalations for further information.

Auto Restart-Notifications Policies

You can configure an Auto Restart-Notifications Policy to start the notification flow for an alert from scratch if the problem is not resolved within the time threshold of your choice. At the end of the day, it's another policy type and you don't have to deal with the possibility of matching another notification policy.