Dear Atlassian Community,
We are currently facing some challenges in understanding and managing the behavior of Responder Alerts within the new Jira Incident Operations, following the integration of OpsGenie features with Jira Service Desk. We have been unable to find specific documentation that clarifies how these alerts function in the current environment, which is causing some issues in our incident processing workflow.
Our current setup involves a list of services and an Automation for Jira rule that triggers when an incident is created. This rule analyzes the ticket (summary, description, and custom fields) for keywords to:
- Associate the relevant service to the Affected Services field.
- Update the priority based on urgency, impact, and the affected service.
This part of our automation is working as expected. However, we are encountering the following problems with Responder Alerts:
Unintended Notifications for All Priorities: Responder Alerts are being triggered for incidents of all priorities. When a service is linked to Affected Services, Jira automatically adds the service's owner (which is a group in our case) to the Responders field. This correctly triggers an alert to the entire team based on our escalation policies for P0 and P1 incidents. However, the system also generates a Responder Alert for lower priority incidents, unnecessarily notifying the on-call person according to the escalation policies, regardless of the incident's severity.
Unnecessary Notifications Triggered by Assignee Field Updates: The Responder Alert system generates a specific alert for the assignee of an incident. This becomes problematic in conjunction with the issue described in point 1. Since an initial Responder Alert is triggered to the service's owning group upon incident creation (regardless of priority), if the assignee happens to be the on-call member of that group, they receive a duplicate notification – one for the group alert and another specifically for being assigned. Furthermore, even if the assignee is not part of the service's owning group or the on-call rotation, a Responder Alert is still triggered for them upon assignment. This is particularly disruptive for lower priority incidents (<=P2) that are assigned via round-robin. In such cases, both the on-call person (due to the initial group alert) and the assignee (due to the assignee-specific Responder Alert) receive notifications for incidents that may not require immediate attention, such as a P5 informational ticket.
We have attempted to disable the Responder Alerts feature entirely, intending to rely solely on integrations and routing rules. However, Jira actively discourages this by displaying a persistent notification to all agents entering an incident, stating that Incident Management features are not active and prompting them to contact an administrator.
We would greatly appreciate any insights, clarifications, or pointers to relevant documentation regarding the intended behavior and configuration options for Responder Alerts in Jira Incident Operations. Understanding how to properly manage these alerts, especially concerning different priorities and group assignments, is crucial for optimizing our incident response process and avoiding unnecessary notifications.
Thank you for your time and assistance.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.