Nick Haller Atlassian Team

Hi @Robert Fernandez , Customers typically integrate JSM and Opsgenie to have JSM issues create Opsgenie alerts, have Opsgenie alerts create JSM issues, or both! The integration is bidirectional meaning that any action taken in either system can reflect in the other. The JSM Opsgenie document will explains how both can be…

Hi @Theis Joergensen , That error can usually be corrected with using an API token in the password field of the integration here: In JSM click into your profile icon → Profile → Manage your account → Security tab → Under the API Token section, click: Create and manage API Tokens → Create API token → Name token something…

Hi @Dan Allenby , Alerts close if it's done manually by a user, through the integration, or through a notification policy if it's configured to auto-close alerts. They will remain open unless one of these three actions is taken on the alert. "We have quite a few alarms that come in and then auto close without intervention"…

Hi @David Dumas , Notification policies can delay / suppress notifications during after hours, and notify at the start of the next day (or next business day). That policy might look something like this: Note that notification policies are only available on the Standard and Enterprise plans, so if your plan does not offer…

Hi @Oscar Rosales , The Incoming Call integration is not available for any JSM plans at this time, and ONLY available for Opsgenie standalone Standard and Enterprise plans. You can follow this feature request for any updates on the Incoming Call integration being added to JSM…

Hi @Steve Fournier , Looks like that "Incident Raised" alert triggered the creation of an incident - which means there must be some Incident Rule automating the creation of an incident through the JSM issue. You should be able to click into alert #117 to see how that incident was triggered.

Hi @pavol_cvincek01 , OEC can realistically be installed on any server or machine. 

Hi @Dan Allenby , It's not possible to notify on each increase in alert count. That's basically the key concept and idea behind alert deduplication to prevent alert fatigue. Deduplication is dependent on the alias field of the alert - which can be edited on other plans like Standard and Enterprise - but not really on the…

Hi @Donny Gison , I don't believe there's a way to control this; "an option to ACK or CLOSE via SMS without charges." I think that simply has to do with message & data rates applying. But we do have a mobile app where users can ack or close the alert with no additional costs, which might be a good alternative:…

Hi @Julian Scharf , Notifications policies can be used to suppress / delay alert notifications outside of work hours. You can configure this under the team's Policies tab, and it might look something like: Note that notification policies are only available on the Standard and Enterprise plans. So if your plan does not have…

Hi @Donny Gison , Glad you figured this out, but I still wanted to share with the Community what the issue is since we come across this quite frequently. If you review the alert's activity logs, you'll see this team's routing rule is sending alerts directly to the on-call schedule - essentially skipping over the escalation…

Hi @bruna.ziviani , If you have your Jira instance configured with Opsgenie through a Webhook, you can control which Issues trigger the integration through the JQL of the Webhook. It'd look something like this: But if you are using the new Jira integration framework, you can also filter on which issues create Opsgenie…

Hi @ati bárdos , Can you clarify a bit please? With a Google translate, "Hi, the application is downloaded and you still can't load the program completely? What did I mess up? Or could it be some other reason?" What exactly isn't loading with Opsgenie? 

Hi @João Fernando Jungblut , I see you opened a ticket with our support team as well. We'll work through that for now, and post the results here for other customers to review.

You can add multiple conditions to the filter to meet your use case. The regex shared above is only filtering on the numerical value. You can add another condition to filter on "Current Incoming," "Current Outgoing," etc. - again - whatever your use case is:

I believe that's the only thing you'd need to update for OEC. Unless your cloud instance moves to another server, that may need to be installed there too.

Yes - any message received will review the policy and check the filter's regex - but the policy will suppress notifications on alerts that contain <=10% in the message.

Hi @Marcel Maas , I was able to get this use case working through a notification policy, and a regex expression like: .*(\d{2,}).* The notification policy above would delay/suppress alerts that contain anything in the message field with numbers greater than 2 digits. Here are a few tests I ran as well: The first test,…

Hi @Harshal pore , Would either of these be what you are looking for? List Alert Notes Add Note to Alert

I should have mentioned that alert policies are limited to the standalone Standard and Enterprise Opsgenie plans, as well the JSM Premium and Enterprise plans. If you do not see a Global Policies tab under the Settings menu within your Opsgenie, this functionality is not provided with your current plan.

Hi @Joshua Mathews , Based on your use case, 2 options might be the easiest to complete this. 1) Like you mentioned, using a Dummy Team to receive all alerts. Under this Dummy Team's On-call tab, have all alerts go to one schedule. In the schedule, configure 3 rotations that represent the Red team, Gold team, and Blue…

Thanks for sharing that. Based on the payload shared, you may be able to simply use: {{condition_description}} to extract that field. If either of those suggestions do not work - feel free to open a ticket with support here: https://support.atlassian.com/opsgenie/ You can even reference this Community post and Nick H., and…

Hi @Donna Askew , Unfortunately there isn't a way to auto-close ack'd alerts for something this specific. Notification policies can be used to auto-close alerts after x-time, but they cannot apply only to alerts that are ack'd: The notification policy above does two things; 1) Restarts notifications for Phone Call alerts…

Hi @steven.falconieri , If this field / data is parsing in the payload, you should be able to extract it using either String Processing or Regex. It would realistically depend on how the condition_description is parsing in the payload, but maybe try: {{payload.condition_description}} Feel free to also share a what the…

Hi @Stefan Draber , "Which implementation would you choose and why? Are there any technical or processual 'consequences' when choosing one or the other way?" - There aren't really any consequences of using either. Like you mentioned, both work very similarly. But there is the limitation that service subscriptions are only…

Hi @pavol_cvincek01 , You can continue to use OEC after the migration. Although OEC is primarily used for on-prem instances, we do see customers using it with their cloud instances to map Opsgenie alert fields to specific Jira / JSM issue fields. We also recently released a new Jira and JSM integration framework that can…

Hi @Kevin Watson , The Alerts tab cannot query using regex. There is a similar feature request open that allows for better functionality around wildcards that can be followed here: https://jira.atlassian.com/browse/OPSGENIE-217 As for testing regex expressions, sites like this one can help confirm whether or not an…

Hi @Mathieu Mailhos , isSeen refers to whether a user views the alert in the web or mobile application. So an alert be acked, and not seen. 

Hi @Andrew Bozanich , Do you have an outgoing action that maps certain types of alerts and their priority to Jira issues and the priority of those when opened? Below is an example of how I've been able to map P1 Opsgenie alerts to Blocker Jira issues: