How to Map Alert Priorities in Opsgenie

[#1]

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

1. Advanced integration settings

2. Custom Value to Opsgenie Priority

3. Alert policies

Advanced integration settings 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 - Advanced integration settings

A number of Opsgenie integrations parse a priority, severity, 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 the Advanced settings of the integration will empower you to fully customize alerting. You can define when Opsgenie should create an alert, close an alert, add a note, etc. - or in this case map an alert to the correct priority:

Opsgenie provides default actions for every integration. You can edit these actions, and add others to meet many use cases. To map alerts to the correct priority, multiple create alert actions can be configured to manage which alerts are set to P1-P5.

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

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

Actions 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 action maps to P1. If Jira creates an issue with a “Critical” priority, Opsgenie would skip the top action since its filter and conditions do not match the incoming payload. Opsgenie would then review the following create alert action, and map to P2:

2 - Custom Value to Opsgenie Priority

If your tooling parses numerical values 1-5, using Custom Value to Opsgenie Priority offers a simpler setup than #1 because only one create alert action is needed instead of multiple.

If Custom Value to Opsgenie Priority is chosen, a new field - Mapped Priority Value - will be shown to give the expression to define how you want to parse the priority from the payload.

The result must be one of the priority values that Opsgenie allows; P1, P2, P3, P4 or P5. In this field you can drag in dynamic fields, or use string processing methods / regular expressions to extract data that maps the alert priority.

For example with Jira, if the priorities include a numerical value of 1-5, one create alert action 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 in a create alert action, regular expressions or string processing methods can be used to extract fields / data into the alert. Alert policies can then filter on the alert field the data is being extracted into, and modify the alert to map to the correct priority.

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

Some Jira projects require custom fields when creating an issue, but these are not available to filter on in any Jira integration action. As long as the custom field is being parsed in the payload, it can be extracted into the alert.

One of these options 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 configuration extracts a Jira 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 filters on the Opsgenie field, and modifies the alert:

Alert policy applied, 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).