How to Map Alert Priorities in Opsgenie

[#1]

This article covers the three main methods for mapping Opsgenie alert priorities:

1. Incoming | Rules for creating and processing alerts

2. Custom priority

3. Alert policies

Incoming | Rules for creating and processing alerts, and Alert policies are available only on the standalone Opsgenie Standard and Enterprise plans, and the JSM/O Premium and Enterprise plans.

Account Admins and Owners will have permission to configure everything mentioned in this article. Team admins will have permission to configure their team’s integrations and their team's alert policies.

1 - Incoming | Rules for creating and processing alerts

A number of Opsgenie integrations parse a priority, severity, urgency, or field that determines the seriousness of an alert. Most of the time these fields do not map 1-to-1 with Opsgenie’s alert priorities, so Opsgenie will default the alert’s priority to P3.

Using Incoming | Rules for creating and processing alerts of the integration will empower you to fully customize alerting. It's a way to automate the behavior of new or existing alerts in Opsgenie when they are triggered by an event that occurs in the integrated application. Rules can acknowledge or update and alert, add a note to an alert, close an alert, or create alerts.

In this case, map the priority at alert creation:

Opsgenie provides default rules for each integration. Integration rules can be easily edited and/or added to meet many use cases. To map alerts to the correct priority, multiple create-alert rules can be configured to manage which alerts are set to P1-P5.

For example with a Jira integration - filter on an issue’s priority, then map it to a corresponding Opsgenie alert priority:

ALL rules are reviewed in a top → down order, and the first matching rule will execute. Once this happens, no further rules are evaluated - so order sometimes matters!

Meaning if the first rule is an "Ignore," while the second is "Create alert," and the data Opsgenie received from the integrated application matches the conditions of both rules, Opsgenie stops at the first match - the "Ignore" rule in this case - so an alert would not be created.

Rules follow a simple WHEN/IF/THEN conditional statement; WHEN a request is sent to Opsgenie, and IF the filter’s condition(s) match, THEN have Opsgenie create an alert, close an existing alert, etc.

With the example above - if Jira creates an issue with a “Blocker” priority, the top create-alert rule maps the alert to a P1. If Jira creates an issue with a “Critical” priority, Opsgenie would skip the top rule since its filter and conditions do not match the incoming payload. Opsgenie would then review the following create-alert rule, and map the alert to a P2:

2 - Custom priority

If an integrated application parses numerical values 1-5, using a Custom priority sometimes offers a simpler setup than #1 above. Instead of configuring multiple create-alert rules for each priority, one create-alert rule can manage mapping all priorities.

In the priority field it's possible to drag in dynamic fields offered within each integration, or use string processing methods / regular expressions to extract data that maps the alert priority. Simply "Start typing to add a custom priority."

For example with Jira, if the priorities include a numerical value of 1-5, one create-alert rule can manage mapping all priorities with something like this:

{{priority.extract(/P[1-5]/)}}

3 - Alert policies

If a field is not available to filter on within a create-alert rule, regular expressions or string processing methods can be used to extract fields / data into an alert at creation.

Alert policies are reviewed immediately after alert creation. These can be configured globally to apply to all alerts, and/or under a team to apply only to that team's alerts.

Similar to integration rules, alert policies follow a simple WHEN/IF/THEN conditional statement; WHEN an alert is created, and IF the filter's condition(s) match, THEN modify the alert:

Some Jira projects/issues have required custom fields when creating an issue, but custom fields are not available to filter on in any Jira integration rule.

As long as the custom field is being parsed in the payload, it can be extracted into the alert. One of the options below can typically extract a Jira custom field - but realistically depends on how the field is being parsed in the payload:

{{_payload.issue.fields.customfield_12345}}

{{_payload.issue.fields.customfield_12345.name}}

{{_payload.issue.fields.customfield_12345.value}}

{{_payload.issue.fields.customfield_12345.substringBetween("value=",",")}}

This Jira integration's create-rule configuration extracts a custom field as an extra property into alert:

Custom field shown on the Jira issue:

Custom field extracted and parsed as an extra property in the alert:

Alert policy matched, and mapped the alert to P1:

In order to ensure that we continue to provide useful content, please let us know if this Article is helpful (Thumbs Up/Down). Also, to help us improve, feel free to provide additional feedback (directly in the community).

[Tyler Giles]

Hey Nick!

I seem to be an Admin of our Opsgenie installation, but I do not see the Advanced button, or even Settings>Integration>Integration for that matter. My "integrations" section is under "Teams", and this has no advanced options. I am trying to utilize the Critical priority in Jira, but Opsgenie defaults this to a P3 priority, and I want to make this a P1. Can you assist me in any way? Thank you!