How do you deal with OpsGenie incidents and JSM incidents?

[Charlie Misonne]

Hi Community!

I'm curious about your incidment management workflows in OpsGenie and Jira (Service Management). Personally I have the impression that the intgegration between both could be much better but perhaps I'm missing some key insights.

For me the link between OpsGenie incidents and JSM incidents is vague and I hope to gain a better understanding based on your experiences.
Some thoughts:

Atlassian added the Post Incident Review type to JSM, a concept which is similar to postmortem reports in OpsGenie but now we have 2 differet places to track this. And of course there is the Post Incident Review template in Confluence but I guess this once can be used to link JSM issues to Confluence pages.

We can link a JSM incident with an OpsGenie alert and vice versa but this doesn't create a bidirectional link.

I hoped to see more incident related features in the announcement but it's all about alert integrations.
Are JSM incidents and OpsGenie incidents not meant to be used together?

Couple of related questions:

When getting an alert in OpsGenie

1. When do you create an incident in OpsGenie?
   1. How do you create that incident? Via automation rules or manually?
2. Do you create an incident in JSM when creating an OpsGenie incident?
   
   1. How?

When getting an incident in JSM

The major incident no longer creates incidents in OpsGenie automatically.

1. When do you create an OpsGenie alert from it?

[Elmer Hahn]

We currently are ignoring the Opsgenie side of incident management, because of the lack of bi-directional information sharing and linking. Incident management happens in JSM. Though even this could be improved upon.

Things I live about Opsgenie:

• How it auto generates a post mortem
• how it links and can mass clear alerts
• incident investigation features

However everything else we do lives in JSM and without a lot of extra manual work getting this info into JSM is just to tedious. So instead we just use JSM to manage the Major Incidents, Proforama for our Post-Mortems and call it a day.

[Dave Caplinger]

Many months later, the situation is still very frustrating and the goal of having the Opsgenie functionality available from within Jira Service Management appears to still be very far away. Every step forward seems to have a corresponding undesired side-effect that must be worked around.

To respond to the question, my (possibly flawed) understanding is:

• JSM Incident ≈ Opsgenie Alert
• JSM Major Incident ≈ Opsgenie Incident

It's possible to automate creation of JSM Incident issues from Opsgenie Alerts... but they appear in JSM with no request-type set, so they don't appear in the JSM list of open incidents. I worked around this by adding a Jira Automation to force the Request Type to be an Incident.

Opsgenie has Extra Properties that can be useful for identifying what Service an alert is about (so you can identify the correct response team)... but it doesn't share this information with JSM, so I can't even work around it using Jira Automation.

You can (manually) assign an Affected Service to the JSM Incident, which will then identify the relevant responder team and trigger Opsgenie Responder Alerts to the team members... but also it will cause new JSM Incident tickets for each Responder Alert. I worked around this by adding filtering to the JSM Integration config within Opsgenie.

You can automate closing JSM Incidents if the corresponding Opsgenie Alert is closed... but the JSM Incident issue doesn't get a Resolution value, so the Incident still appears on the JSM list of open incidents even though it's Status is "Cancelled." Again, I worked around it with Jira Automation. Also, it doesn't seem possible to make this auto-close behavior conditional, such as not to close if the Incident is assigned or in-progress.

JSM can escalate a regular Incident to Major Incident... but it does not create a corresponding Opsgenie Incident, nor use the Opsgenie functionality for managing incident response such as starting a conference bridge, capturing the timeline, communicating with stakeholders, etc. Other than setting the "this is a major incident" flag to 'true,' I'm not sure it really does anything at all. The workaround is to manually use Opsgenie in addition to JSM (but you can manually link the two objects).

Likewise, JSM has a new issue type for Post-incident Review... but it does not connect in any way to the Opsgenie Postmortem functionality. It doesn't really seem to do anything at all, except give you another ticket type to collect comments and hours in. The workaround is to manually use Opsgenie and ignore or disable PIR issue types in JSM.

At this point, I'm having a hard time recommending use of JSM for Incident Response at all, and there seems to be little reason to integrate Opsgenie with JSM unless your use case is only to use Opsgenie as a "smarter notifier with on-call schedules" for JSM, but in that case you would be ignoring most of the value of Opsgenie.

[Jake Daniel]

@Charlie Misonneare you still seeking feedback in this area ?

Are you aware of any Atlassian users who DO use both OpsGenie incidents and JSM incidents in tandem ?

Thanks in advance.

[Charlie Misonne]

Hi Jake,

I have not used the OpsGenie incidents myself yet.

Any feedback you have about this can still be interesting for the community.