We are using the cloud version of Atlassian products now, but I think the Data Center version we used earlier was much more user-friendly. There are lots of limitations in the cloud version The add-on or features that work with the Data Center versions are not compatible with the cloud version.

Opsgenie fits on top of the base application, which is Jira Service Management. Jira Service Management is an investigation. Previously, we had Jira Service Management and PagerDuty running on top of that. Now, Opsgenie is bundled as a part of JSM. However, when we switched to the cloud version, many of the features have become a bit complicated compared to the Data Center version I had used for years. It might be due to an architectural change or some other reason:

Also, it would be nice if Opsgenie had the ability to import rosters from other sources like you can do in PagerDuty. 

There is always room for improvement with any tool. They could introduce many more features, which we believe is on their roadmap. If we want specific features, we have to create tickets for Atlassian, and their people can oath. If they get a suitable oath on a specific feature, they will implement it.

When I needed to add the fourth guy to the on-call rotation, I had trouble finding the option in Opsgenie where I can add the new user. It took me some time to figure out because the icon was very small. You have a pencil icon that you need to click, but it was so small and in a place that wasn't so obvious, so this is an area for improvement in the solution. I couldn't find the icon myself and my manager had to show me where it is. Opsgenie needs to be more user-friendly, particularly when it comes to finding the "Add New Users" option in the on-call rotation feature. Other than that, the solution was very easy to use, and you can see both the open and closed alerts.

The API could use some work. It's the second time around or the second company in which I have had to work on some customizations using Opsgenie, and the API lacks a few features. It could use some work.

I would like to see a little bit more work in API key management in the Opsgenie UI. It's a bit difficult to manage sometimes. For example, in terms of management, you can either see all the keys or none of the keys. This is something for which I would like to have better granularity so that I could give some people access to some of the keys. It's something that I don't have today if I'm not mistaken.

When using the API at some points, on more than one occasion, Opsgenie gave me an error that was not really the reflection of the actual error going on. We had to spend a lot of time debugging and trying to figure it out, and that was a waste of time. We can't rely on the output that we're getting from the platform. This is a bit concerning. It's something that could use some work.

I'm not sure if this is already added, but the last time I looked at incident seeker, which was several months ago, it lacked roles during incidents. So, you have a person taking care of the incident, but you don't have multiple people with different roles during the incident. This is something that I would like to see, but I need to confirm this because the last time I looked into it was several months ago. We even decided to go with a different tool when I looked because I had to do an assessment and compare some of the tools, including Opsgenie. We decided not to use the incidents feature of Opsgenie because it lacked well-defined roles during incidents. This is something that I would like to see so that we could go back and consider Opsgenie as our management tool for incidents.

We have had some difficulty managing the people who leave the company. We even had to write a script of our own to control this because it doesn't seem like Opsgenie has a tool for turning off those users automatically. This is something that I would like to see in the future.

My opinion is more relevant when we have an auto-generated call. Typically, the alerts are vague at times. However, when the automated callers begin reading that alert, it does not make sense to us. 

It would be beneficial to include a feature in Opsgenie where a label is provided with specific words for the alerts.

Opsgenie could refer to that one word rather than reading the full alert from beginning to end. 

Perhaps there is an IP, or an error has occurred, but it is not impressive to have Opsgenie begin reading everything. 

There should be a feature in which Opsgenie reads a label. That would be more appropriate.

A labeling feature would be beneficial.

I would like to see reports that can provide us with integration with Jira or with another management solution, which I'm not sure Opsgenie provides.

The integration is possible, however as Opsgenie reports is an area that needs to be addressed. An alert is received, and Opsgenie will immediately generate a ticket or card for that issue, track it, and provide a follow-up. Opsgenie will also track an issue's whole life cycle. This is something that I would like to see in Opsgenie.

Not just Jira. It's incident management since that's what we use Opsgenie for.

I would want to have an issue management solution that covers the entire life cycle. They will begin with Opsgenie and work their way to the end. 

To have Opsgenie follow up, perhaps by sending a communication to management that this issue is still not been resolved, or something similar. 

A report of the entire life cycle.

The user interface could be improved.

The installation of other applications is difficult in Opsgenie. I would like to see more flexible reporting methodologies. Scalability and pricing also need to be improved.

The solution has room for improvement by providing bundle pricing with other products that are frequently used together from Atlassian.

Initially, Opsgenie had bidirectional integration with Jira Service Management, but that functionality has been scaled back. Previously, Opsgenie was adept at managing incidents within its ecosystem, offering seamless ticket transfers between Opsgenie and Jira Service Desk. I valued the ability to push tickets between the two platforms, addressing the need for widespread information accessibility, though it sometimes led to duplication. 

My suggestion would be to reintroduce complete ticket funneling between these systems to streamline operations.

I would like to see improvements in reporting capabilities that could provide additional value, offering deeper insights and analytics for our operations.

It doesn't have a proper way to convert the alerts into incidents. Every alert isn't an incident. A few will have less priority, and a few will be incidents.

The handshake with the monitoring tools can also be improved. When there were a bunch of alerts or the number of alerts was more than a thousand in a minute, OpsGenie wasn't able to handle everything properly. The handshake issues were there.

The ease of access could also be better. It is a little difficult for us to integrate it with our existing SSO. For the configuration, every time, I have to reach out to Atlassian. If they can blend it easily, that would help.

It would help if there is a feature to create an alert from Confluence based on any existing one.

Their documentation can also be improved. Their knowledge base is not sufficient.

In a future release, we would like to receive alerts when a specific threshold is reached and to escalate the reason for that alert. 

OpsGenie needs to keep up with its competitors in terms of new features and pricing.

It should have a lot of plugins. It should also come with cloud integrations, which are not that great with OpsGenie as of now. It should have AWS, Azure, and Google cloud integrations. 

It should also provide automation, that is, it should open somewhere, like orchestration. Something like the orchestration that ServiceNow is doing. That would be great. Orchestration is the main thing. If OpsGenie comes with stack down feature, not completely but some part of it, and orchestration is there, that would be beneficial.