Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Overview

The alerting feature of Jira Service Management helps you build and optimize your service-aware incident management and management systems and processes. Integrate Jira Service Management alerts with integrate with monitoring systems, service management and ticketing solutions, collaboration tools, and other teaming tools. Jira Service Management filters, categorizes, and enriches the alert content. Understanding the Alert Notifications flow can help users

Understanding the alert notifications flow will help you see the opportunities to continue refining incident your response processes. The diagram and descriptions below show an overview of this flow, and the descriptions of each step contain links to more information about the process associated with that step.

...

...

Alert

...

created

The Alert Creation Flow flow precedes the Alert Notifications flow alert creation flow precedes the alert notifications flow and determines whether —  and when —  the Alert Notifications notification flow begins. When the Alert Creation flow initiates the Alert Notifications flow, the Status of the Alert is Open.

a. Alert Creation Flow
During the Alert Creation flow, Opsgenie processes rules, policies, and other operations on incoming data from all sources (incoming Alerts) before the Alert Notifications flow begins.

For example:

i. Filtering and Suppressing Alerts
Opsgenie Integrations can filter incoming alerts and create Alerts or perform other actions (including ignoring incoming alerts) based on matches to configurable conditions. Other Integration rules and settings can suppress Alerts before the Notifications flow begins: no Notifications are sent, but users can access the Alert.

ii. Notification Policies
Notification Policies can delay the beginning of the Alert Notifications flow. Opsgenie checks incoming alerts from all sources during the Alert Creation flow and can be configured to delay the Alert Notifications flow until a source has attempted to create an Opsgenie Alert with the same Alias (unique identifier for Alerts) a set number of times.

iii. Deduplication
If incoming alerts from any source attempt to create a new Opsgenie Alert when there is already an open Alert with the same Alias, Opsgenie deduplicates the Alert. Deduplication increases an Alert’s Alert Count value by one, instead of creating another Alert. Opsgenie adds these events to the Alert’s Activity Log (to enhance tracking).

Although Opsgenie continues to deduplicate Alerts (as long as their state is Open), the Alert Count value and Activity Log stop showing deduplication activity after 100 occurrences.

b. Alert State
When an Alert is an alert is first created —  manually or through an integrated tool —  the Alert’s state is Open and Unacknowledgedapplication —  the alert’s status is “open” and “unacknowledged”. Over the course of an Alert’s lifecyclean alert’s lifecycle, its state changes as a result of the operations of rules, policies, and user actions. Whether Opsgenie Jira Service Management sends an Alert Notification alert notification depends on the state of an Alertalert.

Opsgenie Jira Service Management checks an Alert’s alert’s state during every step of the Alert Notifications alert notifications flow. The Notification flow of any Alert ends if Opsgenie determines that an Alert is Closed —  through actions of a user, an Auto-Close Policy, or an Integration Close Alert Rule.

2. Auto-Close Policies Processed

When Alert content matches conditions of an Auto-Close Policy, an Auto-Close event is triggered. When the time set for an Auto-Close event arrives, Opsgenie automatically closes the Alert.

3. Auto Restart Notification Policies Processed

If you set an Auto Restart Notification Policy, the current Notification flow is discarded and restarted (regardless of the current Recipient or Escalation states) following a policy-specified time after an Alert’s creation —  as long as the alert is not Closed. So, an Open Alert moves on to Step 3, regardless of its current state.

The following policies are also re-triggered and their time states are refreshed:

  • Auto Close

  • Notification Policies with Delay or Suppress options

4. - 8. Who Should be Notified?

What happens to Alerts next depends on whether immediate Alert Recipients or Teams are identified in the Alertnotification flow of any alert ends when an alert is closed —  it could be through user actions or a close alert rule set in an integration.

Responders to notify

What happens to the created alerts next depends on whether immediate alert responders or teams are identified in the alert.

  • If only immediate/individual Recipients or both individual Recipients and Teams are specified in Alert content (4)individual responders or both individual recipients and teams are specified in the alert content, they are added to the Alert Notification (8)the alert notification.

  • If only Teams only teams (no immediate Recipientsimmediate responders) are specified in Alert content (5)in the alert content, then what happens next depends on whether that team has a matching Routing Rule (6)matching routing rule.

    • If there is no matching Routing Rulematching routing rule, then no Notification is sent (Team members no notification is sent. The team members can still view and access the Alert)the alert.

    • If there is a matching Routing Rulematching routing rule, then the first matching Routing Rule routes the Alert Notification according to the Team’s Escalation or On-Call Schedule -- matching routing rule routes the alert notification according to the team’s escalation or on-call Schedule, or to no one: Team members  Team members can still view and access the Alert (but no Notification is sent). (7)

...

    • the alert.

Routing rules are not triggered if even one individual Recipient is individual responder is specified in an Alert. The Alert Notifications flow moves on to (11) (if an organization’s Opsgenie plan includes Policies) or to (15) (if the plan does not include Policies).

9. - 10. Escalations Processed

If an Escalation is an alert.

Escalations to process

If an escalation is triggered (no matter when the Escalation was the escalation was added to the Recipients fieldresponders), Opsgenie Jira Service Management starts processing Escalation Rules (9) escalation policies to see whether to add new Recipients responders to an Alert Notification. Opsgenie alert notification. Jira Service Management checks these rules against Alert the alert states.

For example:

  • If an Escalation Rule notifies Recipients only about Alerts that have not been Acknowledged an escalation policy notifies responders only about alerts that have not been acknowledged (or that have been Unacknowledgedbeen unacknowledged), Opsgenie Jira Service Management only adds new Recipients to an Alert Notification if new responders to an alert notification if the Alert is both Open and Unacknowledged (“if not acked”)both “open” and “unacknowledged”.

  • If the Escalation Rule notifies Recipients only when the Alert is not Closed, target Recipients are added to the Alert if the alert is Open the Escalation Rule notifies Recipients only when the Alert is not Closed, target Recipients are added to the Alert if the alert is Open -- even if the Alert has been Acknowledged.

If an Escalation Rule adds any Teams as new Recipients, the Notifications flow starts for the added Team Recipients at Step 6. If it adds any Individual Recipients, the Notifications flow begins for these new Recipients at Step 8 —  whether these Recipients are single users, other members of a team, or members of an on-call schedule.

11. - 14. Notification Policies Processed

Some Opsgenie plans let an organization’s Administrative users apply different operations to Alert Notifications by means of Notification Policies. If an organization’s plan does not include Notification Policies, then the Notifications flow continues at (15). If an Alert’s content matches a Notification Policy’s conditions, however, Opsgenie processes Notification Policies (11).

Users set Notification Rules (related to how Alert Notifications are delivered to them) on the Notifications tabs of their own Profiles. Opsgenie processes Recipient Notifications settings in (17).

Were Notifications Suppressed (12)?
If a Notification Policy suppresses an Alert Notification, Opsgenie does not notify any of the Alert’s Recipients, although users can still access and take action on suppressed Alerts.

Integrations can suppress Alerts during the Alert Creation flow. The Alerts Notifications flow does not begin when an Integration suppresses an Alert during the Alert Creation flow.

Were Notifications Delayed (13)?
If a matching Notification Policy delays Notifications, a delay event is triggered. When the time set for the delay ends (14), the flow continues.

Notification Policies can also delay Alerts during the Alert Creation flow. When Alerts are delayed during the Alert Creation flow, then an Alert is not created —  and the Alert Notifications flow does not begin —  until a source has repeatedly attempted to create an Opsgenie Alert with the same Alias (a configurable number of times).

15. Alert State and Recipient Readiness are checked

Before Opsgenie sends Notifications, it checks to make sure that Recipients are ready.

Recipient is ready:

  • Whenever the Recipient was added -- as long as no matching Policy adds a delay.

  • Whenever the Recipient was added plus any delay time -- if a matching Policy adds a delay.

...

  • the Alert has been Acknowledged.

Alert state and recipient readiness to check

Before Jira Service Management sends notifications, it checks to ensure that responders are ready. It then checks the state of alerts one more time:

Alert Statestate

Result

Closed

Recipient(s) are Responders are not notified.

Open and Acknowledged

Recipients are Open and Acknowledged

Responders are no longer notified, except if an Escalation has a Rule that an escalation policy hat requires notifications as long as an Alert is not Closedan alert remains open.

If user action Unacknowledges an Alerta user unacknowledges an alert, the Alert Notifications flow restarts at Step 1.

Open and Unacknowledged

Recipients who have not seen Alert Details are notified: if a Recipient displayed Alert Details (in Opsgenie or any communication channels), then that Recipient alert notifications flow restarts from the beginning.

Open and Unacknowledged

Responders who have not seen the alert details are notified. If a responder viewed the alert details, then that responder is not notified.

Exceptions:
Recipients Responders who have viewed Alert Details the alert details may still receive Notifications notifications for Delayeddelayed, Snoozedsnoozed, or Suppressed Alerts.
Opsgenie turned off alerts. Jira Service Management still sends Notifications notifications to Recipients responders who received an Alert alert because of an Escalation —  escalation policy, but who viewed the Alert Details alert details before the Escalation Notificationescalation notification.

If

user action Unacknowledges an Alert

a user unacknowledges an alert, the

Alert Notifications flow restarts at Step 1

alert notifications flow restarts from the beginning.

16. User Notification Settings Processed

...

Notification settings to process

You can set notification rules that determine how Jira Service Management delivers notifications to them. Jira Service Management processes these notification settings according to the following priorities:

In Alert content (when Alert was

When User Identified a user is identified as a Recipient

Notification Rule Opsgenie Applies

Between Steps 3 and 7

New Alert Notification Rules

recipient

The notification rule Jira Service Management applies

In alert content (when the alert was created)

New Alert Notification Rulesalert notification rules

As a result of Snooze or Unacknowledge actiona Snooze or Unacknowledge action

New Alert Notification Rulesalert notification rules

When User or Team added a user or team is added to an existing Alert:existing Alert

New Alert Notification Rulesalert notification rules

As a result of other Alert actions:Acknowledge action > Acknowledged Alert Rules
Close action > Closed Alert Rules
Assign action > Assigned Alert Rules
Add Note action > Add Note Rulesother alert actions

Acknowledge action > Acknowledged alert rules
Close action > Closed alert rules
Assign action > Assigned alert rules
Add note action > Add note rules

As a result of other User action:user actions

New Alert Notification Rules

If a Recipient has set Forwarding Rules, Opsgenie forwards the Alert Notification to the new Recipient for a set time frame: the Notifications flow ends for the original, replacing the previous Recipient and adding the substituted Recipient in the flow before Step 15. Even after the period for the forwarding rule expires, the previous Recipient will no longer receive updates for that Alert Notification.

alert notification rules

For the Add Note, Acknowledge, and Close actions, Opsgenie Jira Service Management sends a notification only if recipient the responder is aware of the alert. This means, either recipients responder has already been notified about the alert, or they have seen the alert.

17. Is a Contact Method Enabled for a Matching Notification Rule?

...

Contact methods to activate

Jira Service Management can send notifications only if you activate a contact method for a matching notification rule. If there is no matching Notification Rule or if no Contact Method is enabled for the matching Notification Rule, then Opsgenie will not send an Alert.

18. Alert Notification Sent

Opsgenie sends the Alert Notification to one or more Recipients according to the Contact Method selected matching notification rule or if no contact method is activated for the matching notification rule, then Jira Service Management won’t send a notification.

Alert notifications to send

Jira Service Management sends alert notifications to one or more responders according to the contact method selected by each user.

Info

Some user actions interrupt or change the Alert Notifications the alert notifications flow.

For example:
If a team member assigns an Unacknowledged Alert to a user, then the Alert Notifications flow continues for all an unacknowledged alert to another memeber, then the flow continues for all the users being notified: there . There is no effect on the flow, except that the newly-assigned user receives an Assigned Notification -- if s/he has enabled a matching Notification Rulea notification for the “assigned” state if they’ve turned on a matching notification rule.
If a team member Acknowledges an Alert member acknowledges an alert (before assigning it) , however, the existing Alert Notification flow existing alert notification flow stops for the rest of the team and starts for the newly-assigned userrecipient.