Head Of DevOps at a tech vendor with 11-50 employees
Real User
Top 5
Jul 13, 2026
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.
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.
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.
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.
PagerDuty Operations Cloud and incident.io compete in the incident management sector, with PagerDuty Operations Cloud having a feature advantage and incident.io offering cost benefits.Features: PagerDuty Operations Cloud provides extensive automation, advanced alerting, and integrations with major IT systems. Incident.io offers streamlined collaboration, real-time updates, and intuitive interfaces for rapid incident resolution.Ease of Deployment and Customer Service: PagerDuty provides...
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.
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.
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.
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.