The alert notification flow

Overview

The alerting feature of Jira Service Management helps you 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 will help you see the opportunities to continue refining your response processes.

Alert created

The alert creation flow precedes the alert notifications flow and determines whether and when the notification flow begins. When an alert is first created —  manually or through an integrated application —  the alert’s status is “open” and “unacknowledged”. Over the course of an alert’s lifecycle, its state changes as a result of the operations of rules, policies, and user actions. Whether Jira Service Management sends an alert notification depends on the state of an alert.

Jira Service Management checks an alert’s state during every step of the alert notifications flow. The notification 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 responders or both individual recipients and teams are specified in the alert content, they are added to the alert notification.

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

    • If there is no matching routing rule, then no notification is sent. The team members can still view and access the alert.

    • If there is a matching routing rule, then the first matching routing rule routes the alert notification according to the team’s escalation or on-call Schedule, or to no one: Team members can still view and access the alert.

Routing rules are not triggered if even one individual responder is specified in an alert.

Escalations to process

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

For example:

  • If an escalation policy notifies responders only about alerts that have not been acknowledged (or that have been unacknowledged), Jira Service Management only adds new responders to an alert notification if the Alert is 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 -- even if 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 state

Result

Alert state

Result

Closed

Responders are not notified.

Open and Acknowledged

Responders are no longer notified, except if an escalation policy hat requires notifications as long as an alert remains open.

If a user unacknowledges an alert, the 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
Responders who have viewed the alert details may still receive notifications for delayed, snoozed, or turned off alerts. Jira Service Management still sends notifications to responders who received an alert because of an escalation policy, but viewed the alert details before the escalation notification.

If a user unacknowledges an alert, the alert notifications flow restarts from the beginning.

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:

When a user is identified as a recipient

The notification rule Jira Service Management applies

When a user is identified as a recipient

The notification rule Jira Service Management applies

In alert content (when the alert was created)

New alert notification rules

As a result of a Snooze or Unacknowledge action

New alert notification rules

When a user or team is added to an existing Alert

New alert 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 rules

As a result of other user actions

New alert notification rules

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

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 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.

Some user actions interrupt or change the alert notifications flow.

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