Team Policies

📘
Policies are available on our Standard and Enterprise plans.

Team Policies include Alert Policies and Notification Policies that will be explained in detail in the following section. Within the alert creation and notifications flow, at most one policy from each type of each scope, namely Global Policies and Team Policies, can be applied for a single alert (if Continue to Next Policy option is not enabled).

👍
It is important to note that the difference between Global Policies and Team-based Policies is that Team-based policies are tied to an integration, and thus, a team. Global Policies are applicable to any alerts which match the conditions specified under them.

When an alert is created, first Alert Policies defined in the scope of Global Policies are checked and 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. Then Alert Policies and Notification Policies defined in the scope of Team Policies are checked and applied to the alert if the necessary conditions are fulfilled.

Define several policies that are operative for different kinds of alerts to control alerts and their notifications inclusively. For example, define a Notification Policy in the scope of Team Policies to delay notifications for all or some of your alerts based on the policy's condition set to delay notifications for alerts from different integrations at once.

🚧
A team's policies are only applied to alerts that satisfy either one of the following conditions:
- Alert is created with the same team's integration.
- Alert is created with a global integration, but is routed to this team only.
- Alert is created via an incident and this team is the owner or responder of the incident.

Alert Policy

Alert policies can intervene and modify any alert while it is being created. Change or append alert properties like the message, description, or even responder of the alert before it's created. Assign Teams or Users as responders as well.

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

📘
Alert policies defined in the scope of Team Policies are processed as soon as Alert policies defined in the scope of Global Policies processing is completed.

Notification Policy

Notification Policies are available only in the scope of Team Policies. In other words, Notification Policies exist only under Teams. Notification policies apply to notifications of alert actions, like new alert creation, acknowledge notifications, etc. Apply different operations to all team alert notifications, using Notification Policies. Specify which type of alerts the policy applies to.

There are 3 types of actions provided by Notification Policies: delay/suppress, auto restart, and auto close. Details of these actions are explained below.

📘
Policies are available on our Standard and Enterprise plans.

Delay/Suppress
Suppress option prevents all notifications for any alert that the policy applies to. In other words, when an alert is matched with a notification policy that has a suppress option, no one is notified for alert creation or any alert action.

The delay option delay alert notifications for a specified fixed time or until the desired day of week and time. 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 are not 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 are delayed for the specified fixed time which could be 7 days at most. If Until option is selected, the notifications are delayed according to the following patterns for each option:

First HH:MM Alert notifications are delayed until the first specified HH:MM based time on any day.
Next Weekday at HH:MM Alert notifications are 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 are 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 are delayed until March 7, Monday 08:00. However, if the alert is created on Feb 28, Sunday, the notifications for the alert are delayed until Feb 29, Monday 08:00.

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

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

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

Auto Close
Auto Restart
Delay/Suppress

Therefore, the auto restart 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 action to repeat 20 times at most for a single alert.

Auto Close
Auto close actions can ensure all your alerts to be get closed eventually. The alerts that match an auto close action 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 auto close action. If the alert gets closed in the mean time, no action is taken.

Action Policies

Action policies execute Opsgenie actions without manual effort. Opsgenie actions can reduce the response time of predictable or repetitive alerts with Action policies. Run simple actions such as restarting an instance or increasing table capacity without waiting for the response of an on-call responder. Action policies can be used to define such acts on Opsgenie actions.

To configure Action policies, please follow these steps:

Click Add action policy then define the Policy name and Policy description.
Configure the alert conditions to specify which alert triggers the policy.
Set conditions for the alert message, description, responder, tag, and more, provided by drop-down menu.
Select an Opsgenie action to execute when the given conditions are satisfied. Specify the required time to execute action after the alert creation.

Action policies have an option to process more than one policy. If the 'Continue to next policy' option is enabled, the next policy is processed. This chain execution stops at the first policy which has disabled option.

🚧
Action policies are only available for Opsgenie actions. Therefore, Action Policy section is only visible to those customers.