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:
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.
Hello @Mau Jimenez ,
This is Shashwat from Opsgenie support and here to help! :)
May I know what is your Opsgenie instance URL?
Here are the help document resources for Responder alerts in Jira Service Management:
https://support.atlassian.com/jira-service-management-cloud/docs/what-are-responder-alerts/
https://support.atlassian.com/jira-service-management-cloud/docs/sync-incident-details-with-responder-alerts/
https://support.atlassian.com/jira-service-management-cloud/docs/add-and-manage-incident-responders/
Best,
Shashwat
Hello Shashwat!
We do not have a specific url for Ops Genie as it has fully integrated with our Atlassian Site.
Unfortunately, and given our policies, I cannot share the URL through here as it is an open forum, however, I may share some screenshots if that would work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @Mau Jimenez ,
No worries!
Could you please log a support ticket with us using this link ?
Best,
Shashwat
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Shashwat!
Thank you! We have created a ticket for this: PCS-404494.
Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Mau Jimenez and @Shashwat Khare - Is there any way to get some follow up here to help other customers?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Dan!
I'm sorry for the long time it took me to reply back.
Well, to be honest with you, Atlassian support was really kind to schedule a call to go through our instance, however, we didn't ended up changing our setup as it was "a good setup" .
As far as we understood, The Responder Alerts are meant for incidents, in other words, request types that are confirmed incidents (not issues in their way to be confirmed as incidents). As such, we didn't benefit at all from them.
Our setup is as follows. With Responder Alerts disabled, from the main settings page (Top-right gear -> Operations), on the left navigation bar, we created our integrations making sure the "Source" on the "Create Alert" rule was unique and properly formatted.
With that, we went back to the left-navigation bar and created a Sync with the current Jira instance. We did not touched the default settings on the "Rules for creating and processing alerts" but we created custom rules on the section "Rules for taking actions against alerts" to create a ticket for each alert received via integration.
This is the most complex part, due to NDA I cannot disclose the exact details but we used the Ops Genie API to link the alert to the ticket.
And that's it... Our solution to a problem that I really hope Atlassian fixes in the near future.
Hope this helps the community.
Best regards!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.