incident.io Reviews

incident.io is our primary solution for incident management. We receive a lot of alerting from DataDog, Honeycomb, and Prometheus. All these metrics and alerts get triggered based on thresholds that our performance engineers have established based on our user experience and backend performance. When those thresholds spike on an application or in certain scenarios, we receive an alert. Out of that alert, an incident is automatically created if it has been triggered more than three times. Once the incident gets created, we see the severity of the incident and accordingly take action. It creates a Slack channel and everything for us.

The best features in incident.io include the severity level definition, which is very clear, such as whether it is a sev 0, sev 1, or sev 2 incident. The on-call workflows are extremely good. How we have set that on-call workflow is quite impressive; you can do a plug and play kind of thing. You have a canvas, similar to a whiteboard that we use in any of the applications. There, you just bring on the component and plug and play.

For example, our on-call rotation is structured such that the first alert goes to a junior engineer. If within an hour the severity is P2, then it goes to a senior engineer. If the severity is P2 and again, for one hour, no one responds, it goes to the lead engineer, basically my level. If I don't respond, it goes to my manager. If my manager doesn't respond, it goes to the VP of Engineering.

We have better control over incidents on weekends. For a P0 incident, which is critical and blocks customers, we make sure that the first incident responder is a junior engineer along with a senior engineer tagged along. If they don't respond within 10 minutes of the alert or incident creation, an automatic alert goes to the higher availability engineer, such as a lead engineer. If I don't respond properly, then it goes to both my manager and the VP of Engineering within an hour. This is how it works, and we have to take responsibility.

The system provides that you are solely responsible for the incident and you will manage it in and out. You have all the essentials along with it, regarding how you will manage it with a 10-minute window, 20-minute window, and so on. It gives you updates on incidents, and you just fill the form to indicate what status we have reached. This way, we can also provide our customers live feeds on their status, especially if they are dealing with a P0. For P1 and P2, we don't follow that strictly, as we have a very flexible approach where the customer isn't blocked in those scenarios, and we are quite relaxed.

Having an automated workflow feature in incident.io has helped me reduce human error significantly. We were using a better solution such as PagerDuty previously, but the cost implications were extremely high. It charges per incident created. Moving to incident.io was for cost efficiency, as it is almost 50% cheaper based on my experience compared to what we were paying for PagerDuty at that time. However, PagerDuty is a far superior product than incident.io, but incident.io gets the job done.

incident.io's real-time collaboration features have significantly impacted my incident resolution efforts. I've previously mentioned that we follow a hierarchical system to manage our incidents and incident responses. This hierarchy consists of a junior engineer, then a senior engineer, then me as the lead engineer, followed by a manager, VP of Engineering, director, and even the CTO can get tagged. For a P0 incident, which is very critical, we get high returns in terms of incident response.

You can say the on-call flows help immensely. If one engineer is unavailable, we can depend on the team rather than a single person handling everything. It's more of a team effort, and within everyone's team, the observability of incidents is clear. We receive proper alerts on our phone calls and everything, which makes life a lot easier with Slack alerts, phone calls, and email flows all being available.

I would like to see incident.io improved in terms of maturity, as it is not a complete solution at the moment. It narrowly focuses solely on incident management and lacks the breadth of a platform such as PagerDuty, which has a high service catalog encompassing everything from asset management to change management. incident.io is not there yet. It's not so much of a feature request; it's about the niche they're working on. For it to develop further for enterprise-level customers, it needs to transition into more of a platform than just a solution.

When it comes to pricing, I have seen a great ROI with incident.io after switching from PagerDuty. However, I must clarify that those ROIs were also met with PagerDuty, meaning it isn't extensive that we are observing. The MTTR trends are something that is sadly missing in incident.io, which we had with PagerDuty. Cost estimations are also lacking. If an incident occurs, for example, seeing high cardinality metrics in production leading to a jump in billing, those estimations can't be done in incident.io while they could be done in PagerDuty. Thus, it feels more of a downgrade for us, but again, every choice has its pros and cons. incident.io is cheaper, and we needed a more economical solution, as simple as that.

I have been working with incident.io for probably one and a half years. I was using PagerDuty in my previous organization, and this company also had PagerDuty. After that, we switched to incident.io because of cost issues.

When discussing the stability and scalability aspects of incident.io, our incidents are not very frequent; we get less than four to five incidents on a weekly basis. Therefore, I can't ascertain how it would perform for teams experiencing extraordinarily high alert volumes, but based on our use case, it fits well, and we don't encounter any issues.

When discussing the stability and scalability aspects of incident.io, our incidents are not very frequent; we get less than four to five incidents on a weekly basis. Therefore, I can't ascertain how it would perform for teams experiencing extraordinarily high alert volumes, but based on our use case, it fits well, and we don't encounter any issues.

Regarding the technical support team of incident.io, I rely heavily on documentation and don't generally need human involvement. I primarily utilize the documentation provided, as the tech support team will also recommend reaching out via the global incident.io Slack channel for community collaboration. I actively participate in that community to ask questions, and there is always someone from the team to respond if something goes wrong, making it a collaborative experience.

We did evaluate other options available in the market, and we were using PagerDuty, which has a very dense ecosystem. incident.io is specifically a Slack-dependent solution that integrates solely with Slack, while PagerDuty has far more capabilities. For instance, it can integrate with Microsoft Teams, AWS clouds directly, Azure, and even connect to GCP servers, providing better visibility. Currently, whatever alerts we receive come via our observability stack, either Honeycomb, DataDog, or others. But with PagerDuty, you can integrate further down to track AWS-related metrics, which isn't an option available in incident.io right now.

We utilize the incident timeline feature, which helps us track our MTTR. There are certain metrics that we follow as SRE engineers, and MTTR is one of the critical metrics we have to monitor to provide our customers and meet our SLOs. In such scenarios, the timeline of the actual incident assists in tracking how the incident happened and what the turnaround time was during the incident. This allows us to solve issues for customers as quickly as possible.

Apart from MTTR and MTTD, we track MTTR as a definite metric we follow when measuring incident response improvements with analytics in incident.io. The DORA metrics we handle are primarily addressed by Sleuth. Other than MTTR, we don't track many metrics in incident.io because for other metrics, we solely rely on Sleuth for the DORA metrics. DORA metrics indicate team pace, and incident resolution is a crucial factor, which is why we utilize them.

When it comes to the initial setup for incident.io, it is extremely simple. It's a plug and play setup, the easiest deployment I've ever done. Once I started using incident.io, we paid some money, took a version, and were able to get everything set up within a day or so, with everything working as expected. There were certain quirks and flows that needed fixing, but we managed to address those later on.

When it comes to pricing, I have seen a great ROI with incident.io after switching from PagerDuty. However, I must clarify that those ROIs were also met with PagerDuty, meaning it isn't extensive that we are observing. The MTTR trends are something that is sadly missing in incident.io, which we had with PagerDuty. Cost estimations are also lacking. If an incident occurs, for example, seeing high cardinality metrics in production leading to a jump in billing, those estimations can't be done in incident.io while they could be done in PagerDuty. Thus, it feels more of a downgrade for us, but again, every choice has its pros and cons. incident.io is cheaper, and we needed a more economical solution, as simple as that.

In my evaluation process for choosing incident.io, we did consider alternatives such as Jira and ServiceNow, which provide similar functionalities but are comparatively more complex to set up. Being a smaller company, we needed a straightforward solution where everything gets done clearly on Slack since we use it heavily in our operations. Our requirements were very minimal: we wanted an incident manager to create a Slack channel for incidents, alert incident responders, and provide all pertinent details. That use case fits best with incident.io after our experience with PagerDuty.

My advice for others looking to start using incident.io is that if you don't have money, just start with incident.io. You will not regret it. However, if you have the budget, choose a better solution. Why settle for a lower-end solution with limited integration capabilities that relies solely on Slack? If you have the means, go for PagerDuty or consider a comprehensive solution such as Jira, which offers complete ITSM capabilities. incident.io isn't as mature right now; the on-call rotation ecosystem is functional and gets the job done, but for enterprise-level customers with a larger budget, moving to PagerDuty would be a better choice, despite it being costly. I would rate this product 7 out of 10.

I was part of the DevOps engineer team where incident.io was configured to send alerts into Slack channels, such as our war room channel. For any incident, including production issues or P1 or P2 tickets, we received notifications on our mobile devices through incident.io. After configuring our profiles, we received messages, alerts, and calls for P1 tickets.

When our application went down, we received a client email, an incident alert from incident.io, and a Jira ticket. incident.io creates tickets, sends SMS messages, and makes calls to whoever is on call during that particular shift. If something is down, incident.io sends an alert, creates a ticket, and whoever is on call from the team is responsible for investigating the issue. Application downtime or any urgent tickets such as P1 or P2 issues were all received from incident.io.

incident.io is very quick, as it rapidly creates a Jira ticket as soon as we receive alerts. It sends notifications on Slack and SMS messages to mobile numbers. If the person on call does not respond to a ticket within five minutes, incident.io will also make a call to their mobile. These features are outstanding, and incident.io is easily integrated with other software such as AWS SNS, Slack, and Teams, and can integrate with any other software.

incident.io made things easy for us. We do not need to sit in front of the system twenty-four hours a day, seven days a week to check if our application is up or if something is going wrong. This has saved a considerable amount of time for the DevOps engineers. Whoever is on call can relax, and if an issue occurs, incident.io creates the ticket and sends an alert message. incident.io is a very useful tool for our organization. In the DevOps engineer team, we had around five team members, and each of us was on call once a week. If any issues occurred, incident.io would alert us. The main advantage is that we do not need to sit in front of the system twenty-four hours a day, seven days a week, even though we are on call for that duration. If any issues occur in the production environment, incident.io sends us an alert, creates tickets, and calls us on our mobile.

With incident.io, we saved our Service Level Agreements with the client to resolve issues. P1 tickets were solved within thirty minutes to one hour, and P2 tickets were typically solved within seven hours. This helped us maintain our SLA agreement with the client.

I do not think any improvement is required. incident.io is a good application.

I have been working for the last seven and a half years.

No stability issues were experienced.

No scalability issues were experienced.

No customer service issues were experienced.

incident.io was always used in that organization. We did not evaluate other solutions, but I am aware of Opsgenie.

incident.io is a really cool tool. It is very easy to understand, and the user interface is also very nice.

On a scale of one to ten, I would rate incident.io a ten. I do not feel I should give less than ten because it is a great application. I do not find any issues with it, and my experience with incident.io was great. I would rate this review ten out of ten.

We currently have one use case. We are pushing alerts from another tool that we use named Groundcover, which is an observability tool. When we detect that one of our tenants is down, we want to make a critical alert to notify us about that. We need a way to push it to the managers in the company. incident.io was great for that, so we chose it. We are pushing alerts from Groundcover when a host is down. We are using incident.io to get an SMS and a phone call and a follow-up in Slack. This allows us to know about the incident, follow who is managing it, what is happening, and the investigation in the Slack channel. This is a great tool for us. It fits perfectly for the issue that we are having.

First, we tried to use PagerDuty, but our trial ended and everything was blocked. In incident.io, I can use it for free with about five people, if I'm not sure. We are a very small company, so three managers is enough. This was the first point that made me choose them. The second one is the UI. The UI/UX is very nice. It looks very young and very brand new compared to other tools. The option to manage who is in-call and who is out-of-call during the shift is very nice. It's not applicable for us because we are all twenty-four seven, but in the future, we can handle the time that each one is on call and waiting for calls and see the incidents in real time. This is a nice feature that they have. I didn't know if other tools also have that. Having an SMS and a phone call together with a new Slack channel opening for each incident makes the handling in the incident very efficient.

The key benefit is that I now have a tool that can push critical alerts to the support team. Maybe in the future we can build a support team over this tool and move to a paid version if we think this is a good tool. The option to move incidents, critical incidents to be handled using incident.io is a very strong benefit for us because now we have something that can manage the incident lifecycle from scratch. We can know who is managing it, who is leading it, what is the issue, all the follow-up, and maybe report to the customer if needed. It's a very nice tool if we need more features. It's a great door to open and to work with.

Before that, we were just pushing new incidents about a host being down into a Slack channel. But we are not all looking on the Slack channel twenty-four seven. So if we are sleeping or if we are not available, there can be a wait for many times, maybe a minute, hours, or maybe only the morning later. Maybe someone in the US will call us, or the customer will call us and tell us, "My host is down." This is bad for us. Now with an incident, we can handle it in a few minutes. Because the phone call is about ten minutes from the incident, and we are immediately going to the computer and fixing the issue. So it can go from hours to a few minutes.

The integration between Groundcover to incident.io was a little bit complicated. I was using YouTube videos and documentation from both sides, from Groundcover and from incident.io. It took me about one to two days to make all the configuration. A lot of time was lost during those days. We are in two thousand twenty-six. Nowadays, integration between two new tools should be less than a few minutes. If they can make more quick installation or maybe easy guidelines to make a simple incident and to fire it to the customer very easily between Groundcover and incident.io, it will be more useful for me, for example.

I spent about two days on a very complicated setup. This is one thing that I want them to improve. I wanted alerts to send me an SMS and a phone call once an incident is alerting for three people. This was a very simple use case. It took me two days to handle and to configure everything. Even the AI agent didn't help me to set up. Maybe they need to improve the AI agent's information so any AI agent can help the user. Or maybe they need to make a better setup onboarding flow. I'm not sure what is the right thing to do. If they can improve the integration with Groundcover and make it more automatic, it will be more easy for both sides.

About three to four months.

There is no negative impact on the team. It just allows us to give better service. It's not impacting the team negatively. It's just helping the team to be more aware and less worried to miss something. Now we are more aware.

No issues reported.

First of all, the UI/UX. PagerDuty looks very old and very old school. PagerDuty didn't tell me that I finished the trial and locked me out. We didn't know that the host was down until we saw it in the Slack. Once they blocked me, we were blind. We didn't know what was happening. This is bad for my organization. Even if I'm not a paying user, I need to know what is going on. Don't offer a trial if you block me later. This was a bad experience. incident.io gave a free trial, and they give free users for the start. I think it's a good start. The onboarding was very easy in incident.io compared to PagerDuty.

I'm not very familiar with the incident.io UI. I'm just one DevOps in the company, and we don't have any more DevOps. They have a lot of features, but I'm using it only to push alerts.

I am using incident.io in their cloud.

I can tell that incident.io is a very young, nice UI product. It can be very easy to start if you are following the documentation right. It's built up for large teams. They need to make some improvements for small teams, so it will be more easy to make onboarding. Except for that, it's a great tool, working well from day one.

The prices are not high. They look the same as PagerDuty and all others. So they look normal.

The integration between Groundcover to incident.io was a little complicated. I was using YouTube videos and documentation from both sides, from Groundcover and from incident.io. It took me about one to two days to make all the configuration. A lot of time was lost during those days. We are in two thousand twenty-six. Nowadays, integration between two new tools should take less than a few minutes. If they can make more quick installation or maybe easy guidelines to make a simple incident and to fire it to the customer very easily between Groundcover and incident.io, it will be more useful.

I spent about two days on a very complicated setup, which is something I want them to improve. I wanted alerts to send me an SMS and a phone call once an incident is alerting for three people. This was a very simple use case, yet it took me two days to handle and configure everything. Even the AI agent didn't help me to set up. Maybe they need to improve the AI agent's information so any AI agent can help the user. Or maybe they need to make a better setup onboarding flow. If they can improve the integration with Groundcover and make it more automatic, it will be more easy for both sides. I would rate this product a nine overall.

My main use case for incident.io is pushing all the alerts from our observability about critical issues and alerting the main people in the company to let them know about the incident, for example, to myself, the CTO, and the Head of R and D. For example, if a host is down, we are pushing alerts and we're getting SMS and phone calls immediately. This is an easy solution for us.

Now that everything is working, I may add some more alerts in the future, and if I see that it's working properly, I may add some less important alerts.

The best features incident.io offers for me are that it combines SMS, phone calls, and a platform that opens a Slack channel for me, allowing for follow-up and everything inside it. It's very useful to handle incidents.

I find the integration with Slack and the follow-up features to be very helpful because it focuses me in one Slack channel with all the team members that need to be in it, and if I need, I'm adding more members until we figure this out. It's very useful.

Incident.io has positively impacted my organization because every time we have something critical, we respond in a very short time. This is very useful for us and speeds up our support, leading to fewer customers experiencing critical issues in a short time.

I can estimate that our response time has become much faster since using incident.io; before, we got alerts in Slack, and if we were in front of the computer, we would reach out in about ten minutes to half an hour. Currently, when we get the phone call, we are closing the incident in less than ten minutes.

Incident.io can be improved with more integrations with leading observability tools; for example, Groundcover is now leading in observability from my side. I'm the only single DevOps in the world, so if I want to lead my company to use incident.io, it needs to be more friendly and easier to set up, with more integrations with Groundcover that would make it easy for me to integrate. Maybe more guides, something very short and easy to make a simple alert, and a more user-friendly UI, which could be less complicated. I know that incident.io is built for large companies with many teams and many shifts, many kinds of alerts, and many sections, but for a small company starting to use it, such as mine with only one person handling all the issues, we need something more manageable.

I have been using incident.io for approximately three to four months.

I set up the alerting process with incident.io by following some YouTube channels and some documentation until everything worked for the teams, but the separation of schedule—who is working and who is on shift—wasn't working as well because we are twenty-four-seven and don't have shifts. That was somewhat complicated, and we still are in the free version, so I wasn't sure if something is limited or if it's just a lack of information from my side.

I shared what I felt needed improvement. I would rate this review an eight out of ten.

My main use case for incident.io is incident management and conducting root cause analysis for all incidents reported in my organization.

A specific example of how I use incident.io for management and RCA in my workflow is when alerts are set up on our services. Whenever alerts are triggered, we receive a notification. Through the workflow, the specified person is notified that there is an alert on their service, so they can quickly recognize it and resolve it to ensure customers do not face any issues.

incident.io's best features include incident management and the AI features that help us recognize issues and conduct RCA. These features assist in later stages, meaning similar issues can be resolved quickly in the future.

The AI features help me recognize issues and speed up resolution by creating a channel for a particular incident, adding the required people to that channel, and providing the RCA of that incident. They explain the root cause, how it occurred, and what the possible solutions could be.

incident.io has positively impacted my organization by helping with incident resolution and reducing time in incident management. Incidents that previously took about five to six hours to determine the RCA have been reduced to three to four hours, meaning it has helped in reducing time by one to two hours.

The AI features are quite expensive pricing-wise, and the pricing should be reduced. Apart from pricing, there are no other improvements needed for incident.io.

I have been using incident.io for more than 1.5 years.

incident.io is somewhat stable in my experience, and I am exploring it more thoroughly.

incident.io's scalability is good.

incident.io's customer support is good.

Negative

I was previously using PagerDuty and decided to switch because there were fewer features, issues with on-call support, and several features missing that are present in incident.io.

I have seen a return on investment with incident.io, as time has been saved, which is an important metric to consider.

My experience with pricing, setup cost, and licensing was great. The team was helpful in setting up everything. Initially, I faced some issues with integration and permissions, but those were resolved later.