Opsgenie Reviews

We have several different teams that need to be on-call for several different products. So, we use Opsgenie to manage that, and we also use it for routing our alerts from a different monitoring service. 

We also use Opsgenie to control some of our schedules for different activities. For example, we have internal support for some of our teams, and even though this does not require the teams to receive any types of alerts or monitoring, we still use it for scheduling so that it can control who will be the next on-call person.

We are using it as a service. So, we don't host it in any way. I believe we are using the latest version because we do not control its version. It's a service.

We can rely on the product to organize our schedules. We don't have to think about who will be next on-call. The system already gives us the answer. We don't have to waste time organizing how people are going to be covering each of their rotations. There's also an override option. So, it's easy to reschedule or reorganize our schedules when someone goes on vacation or when someone is on sick leave.

It's also easy for us to understand whom to contact when we have an issue. So, if we receive an alert, we have the first person on-call, but we can also organize different people to receive these alerts depending on our rules. 

The rotations are very useful for us, and the routing for alerts is also very useful.

We have the escalation feature, which is pretty neat, and the API is also pretty easy to use. Although it lacks a lot of features that we would like, it's pretty straightforward. So, if we want to do customizations and use the API along with Opsgenie, it's fairly easy to do. It's very well documented.

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.

I have been using it for several years. I used it even before it was bought by Atlassian. Overall, I have been using it since 2013 and then there was this huge gap in which I used a different tool, but for the past three years, I've been using it again.

It's pretty stable. However, on some occasions, the error that Opsgenie gave was not really the reflection of the actual error, which is connected a bit to its stability because we can't rely on the output that we're getting from the platform.

It's scalable, but we do have a problem with the governance of the people who leave the company.

Currently, we have about a hundred users. We have plans to increase the usage. The company is growing, and we have a lot of teams that are not on-call at this point, but they will need to be. So, we are planning to expand.

It has been some time since we had the issue with the API message. If I remember correctly, we were not able to get quick answers. On the technical side, they probably didn't know that this problem was happening. So, the support was not effective for this issue specifically.

I also had to contact them once regarding configuration, and they were pretty quick to understand what the problem was, and they were able to help me. With regards to the configuration using the user interface, their support was pretty useful. It was effective, but with regards to the API, they were either not specialized or didn't have the answer. Both reasons are concerning.

I have some experience with PagerDuty. I used PagerDuty for about two years, but we hated it, and we went back to Opsgenie right after. I'm not sure if that's the case anymore, but PagerDuty was less expensive. That was one of the reasons why we left Opsgenie and moved to PagerDuty. There were also some things that Opsgenie didn't do. I started working for that company after this decision was made. So, I'm not sure about all the details of why they decided to leave Opsgenie at that time, but they did leave Opsgenie, and after almost two years, they decided that the PagerDuty was not good, and they went back to Opsgenie.

One of the reasons for going back to Opsgenie was that PagerDuty had fewer features than we were expecting. If I recall correctly, the main reason was the fact that the provider of the Terraform for PagerDuty was not well-maintained. We had a lot of issues with it, and in our case, we were managing everything as a code. So, it was very important to us that the provider was correctly maintained and had fewer bugs. This was one of the strongest reasons if I recall correctly.

Onboarding people into it is pretty straightforward. Because we use it as a service, we didn't have to do any deployment or any configuration other than the configuration that we had to do for the teams. So, in terms of deployment of the tooling, we didn't have to do anything. In terms of configuring it to work for our needs, it's pretty straightforward. It's not complicated.

For the current company I work for, it was configured by a different team. So, I don't have information about the number of people involved in its deployment. I haven't participated in the configuration for the whole company. I was only responsible for configuring a new team, which was pretty straightforward.

In terms of maintenance, because it's a service, we don't do any maintenance. The only maintenance that we do is our internal one because we use Terraform to build teams. So, this is the only maintenance we do, but it's not really of Opsgenie.

In the company I'm working for, currently, we are using the standard edition of Opsgenie. We're paying around $3,000 a month. It's a bit expensive compared to the other tools we use for different purposes. 

We find it a bit expensive because although Opsgenie is a complete tool for monitoring, it does not provide us with everything. For example, even though Datadog is for different purposes, we get a lot from Datadog. It's a monitoring tool, and we have a lot of things going on there. There are a lot of things that we use. We heavily use it, and its pricing, in the end, is a bit similar to Opsgenie, but Opsgenie offers much less because it has a closed scope. Overall, we're happy with it right now, and it's not a big deal, but it was one of the reasons that a different company decided to leave Opsgenie.

I don't know if everything is included in the cost or if there are additional costs. We pay for users, but I'm not sure if that could be considered as paying separately because if we add a user, our bill will grow invariably.

We pay for seats in Opsgenie. It's a subscription with a set number of users. It's a bit annoying that when we want to add a new user, we have to come and change our subscription and then add the user. I understand this is a safe option, and you don't charge your client without their knowledge, but at the same time, I would like to see an option that allows it to be scaled automatically without having to change our subscription every time.

I would definitely recommend it for a medium or a large company. I've seen it being used in small companies as well, but I'm not sure about the return in terms of money because it was too expensive. In one of the companies, we used it before it was acquired by Atlassian. At that time, the company had 30 people. It was a very small company, and even though we had Opsgenie, it was very expensive. I remember this being a recurrent topic in our meetings.

I would rate it an eight out of ten.

Our primary use case for this solution is on-call rotation, and we deploy it on cloud.

The solution has helped us stay alert on incidents and improved our response times. 

We have found the integration and alerting feature very valuable because it can page you when you are on-call. It is pretty helpful when we have production issues, and some metrics and alarms are configured for notifications and calls. Therefore, it alerts us so we can act when necessary. Additionally, the rotation and scheduling are beneficial.

Previously when we had issues, we would get a notification from Slack, but that wasn't adequate because it wasn't directly to the people on-call. It was just a notification and not a phone call, so it didn't help us because we could not write scheduling, override or get escalation for the notifications. With the service in this product, we can now respond to the incidents that it scales to our team, the SRR team and others. Hence, we know that someone is notified and can act on it.

The user interface could be improved.

We have been using the solution for approximately two years and are currently using the latest version.

The solution is stable.

The solution is scalable. Currently, there are approximately 80 people in our organization using the solution. In addition, around five people are required for deployment and maintenance.

I have never been in contact with the customer service and support team.

I was not part of the first integration but was involved in the integration for scheduling. I worked on defining rotation and creating new things in other rotations. It wasn't hard, but we had some minor issues getting it right the first time.

We implemented the solution in-house.

We have seen a return on investment in this solution.

I am unfamiliar with the licensing costs for the solution.

I rate the solution eight out of ten. The solution is good but the user interface can be improved. My advice to new users with this solution is to integrate as many tools and data sources as possible as well as some alerts and alarms tools.

We use this solution for incident management. If we host a website or run a server, we can get a notification or alert if our system is running. When we integrate it with other web monitoring tools and there is a glitch or function, it automatically creates a ticket or alert. For example, we get a call, a message, or an email, and if we integrate it with the Jira Service Desk, it automatically creates a Jira Service Desk ticket and assigns it to the support team member.

Opsgenie integrates with Atlassian and other web monitoring and incident management tools. I used to work with other Atlassian tools, like Jira and Confluence, and whenever we look for any tool, we prefer to go for a one-family solution because it makes the integration easy. We also compared it with other tools, and Opsgenie worked much better.

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.

We have been using this solution since 2021. Opsgenie was an independent product-based organization but was later acquired by Atlassian in 2020. There are no versions with Opsgenie, and it's a SaaS-based product.

It's a cloud-based product, so we do not update it manually. For example, we can complete updates on Android or Apple phones when we want. But in the cloud version of Atlassian tools like Jira or Opsgenie, they do not send us prompts and update it in the background.

It is a stable solution, and the performance is good.

It is a scalable solution. Atlassian tools used to be restricted to 5,000 users but are now open to any number of users. We need two employees to configure and integrate the solution.

It is a per-user license, and you can create your team and another team. It can be five or ten members, but it's up to them how many systems are integrated with Opsgenie.

I don't believe we have used technical support, but Atlassian support is available for Opsgenie if needed, and I know they are good. There are different response times based on the different types of plans, like basic, advanced, and premium plans. So response will be dependent on the plan.

For technical people, the implementation is easy and not complex. But for non-technical people, implementing it will be a little bit difficult.

We do not have to install it because it's a cloud-based product. We just create an account, and it is good to go within five to 15 minutes. Then we have to configure it. No third party is required, and you can configure it very easily.

There are monthly, and yearly subscriptions with Opsgenie and the per-user license depends on the plan. It varies from about $5 to $15 per month. There are different basic, advanced and premium options, and the licensing costs depend on the plan. For example, in an enterprise plan, there are full feature options, and it costs approximately $30 per user. The standard costs $19 per user, and the basic costs about $9 per user, per month.

I rate this solution an eight out of ten. We work in a service-based organization, and clients come to us for support on Opsgenie. So our role is to configure it for them, but it is their decision on how they want to use and handle it. They also decide how many licenses they want to use.

Regarding advice, it is a good tool, and the integration is seamless. Most companies are using Atlassian tools and can get better integration and support. You can pay for licenses and do not have to deal with different vendors. Under one umbrella, you can access development and incident management tools, like Jira, Confluence, Opsgenie, or any other development-related tool.

We use Opsgenie to create alerts from Grafana and we print those alerts with a format of cases on the Opsgenie console and as well as those interconnected to teams. We have more than 200 people using this solution. 

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

I have been using this solution for a couple of years. 

This is a stable solution. I would rate it a nine out of ten for stability. 

This is a scalable solution. I would rate it a nine out of ten for scalability. 

 I would rate the technical support for solution a seven out of 10.

Neutral

The initial setup is straightforward. I would rate the simplicity of the setup an eight out of ten.

There is not much difference between PagerDuty and Opsgenie. Both are easy to use and convenient from a integrations, automations, APA connectivity and GDA perspective. We chose Opsgenie based on cost and our requirements. 

Whenever Opsgenie involves automations and there is a big number of teams or  applications to handle, a good integration with APA services is required. 

Opsgenie as a product is good. I would rate it a seven out of 10.

Monitoring and interim management are the two main features for which we are using OpsGenie. 

We have an infrastructure with around 400 plus critical nodes that we are monitoring. They are scattered across various geographies and include on-premise switches, servers, other devices, and a few cloud services. There are 10 to 20 engineers who monitor it.

We also do total remediation of our own. If something is broken, we'll try to fix it through our software. 

The use cases also vary depending upon the client's requirements while designing a solution. We are a kind of service provider. We have our own in-house cloud management software. Based on a client's needs, we evaluate and provide the inputs. 

One of the reasons for implementing OpsGenie was to have a completely automated system where there is no need to monitor and call someone if something breaks down. Previously, manual intervention was required. If something went down, it had to be followed up with people and escalated. Now, it is a completely automated system. There is very little manual intervention.

Another reason for implementing OpsGenie was the integration of different alerts in one single console.

The integration feature is the most valuable. It provides a lot of customizations for the integrations we use. 

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

We have been using OpsGenie for almost two to three years.

It is very stable. We feel very good about this. We haven't had any issues or problems with production or operations.

We don't scale up at this moment. 

Sometimes there was a delay from their side in providing a solution, and we didn't like it. I would rate them a seven out of ten in terms of support.

We had completely person-driven or manual management. We had other open-source tools as well for monitoring, but now, we have integrated everything into OpsGenie.

The initial setup was very straightforward. It is like plug and play. It took three to four hours to go live.

We took care of the implementation on our own. In terms of the implementation strategy, we first tested and evaluated it with our lower environment and then re-upgraded directly to the broad environment. It was very straightforward. We didn't have to plan something very complex.

We have seen a return on our investment with OpsGenie. Compared to things like reporting where we used to spend a lot of money, the cost reduction is 20% plus.

Now, we are one centralized team in one place. We don't have a service management team all across the bases, and there's a reduction in headcount as well. We have been able to reduce almost six full-time employees. 

From the pricing perspective, they are on the higher side as compared to other competitors.

We did not really evaluate. OpsGenie was endorsed by one of our other companies and that's why we went with it. We were already using a couple of Atlassian products like JIRA, JIRA Help Desk. The integration with these products is very seamless. That's why we went for OpsGenie.

It's a good product. We never faced any issues in managing this. You can definitely go for OpsGenie if it suits your environment. It's not only about the features and money. You should also feel comfortable with the product.

I would rate this solution an eight out of ten. Every product can have some improvements. We have been using it for almost two to three years in this company. There might be some new features, or other products, like PagerDuty, might have already improved over OpsGenie in terms of the features.

We have a monitoring tool called Nagios, and we integrate Nagios and OpsGenie. The tickets flow from Nagios to OpsGenie. 

We have automation scripts. OpsGenie has the capability to resolve the tickets if it is predefined. If an instance goes down, then to restart the instance, we have inbuilt scripts. When the ticket comes, like instance down or instance failed, we will configure it back to restart the instance. So, that will happen with OpsGenie. It's an incident management tool.

OpsGenie has many features, such as email notification, SMS notification, roster, tracking of the tickets. Automation, like scripting, is also possible.

There are also features for maintaining the history of the tickets and all the solutions related to how it was resolved previously. If there are similar kinds of tickets, we can look at how a person is working on that ticket. If he doesn't have any idea, you can look back at a similar ticket and solve it as the previous person did it. 

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.

I have been using this solution for the last one year. 

It's a scalable solution.

We bought it from a third-party. They're really good, and they're helping. We didn't face that many issues.

The initial setup was very straightforward. The deployment part took one to two weeks. 

Initially, OpsGenie was new to us, so to understand its features, we had a lot of difficulties, mostly on the automation side, such as how to redirect tickets, etc.

I recommend OpsGenie because if you compare with DataDB, the cost is very nominal, like $10 per user. It has almost all the features that DataDB has. It is a good automation tool. It's not only for incident management. You can also use it as an automation tool. It has a good automation environment.

I would rate OpsGenie a seven out of ten. It is a good product, but it needs a few more features.