DevOps and Platform Engineer at a retailer with 201-500 employees
Real User
Top 20
Oct 15, 2026
We are using incident.io for on-call purposes, specifically for alerting and phone calls. We have Grafana alerts, and when something fails or sends an alert, Grafana sends an alert message to our Slack, creates incidents on incident.io, and calls team members on the phone.
The main purpose of incident.io in my work is configuring the on-call team's response to incidents triggered by alerts. A specific example of how incident.io helped my on-call team respond quickly to an incident is that we set up a convenient schedule for responding to incidents. Incidents are tied to the criticality of alerts. We were able to conveniently build the on-call schedule thanks to the built-in functionality of incident.io and we successfully continue working with it. Regarding the main use of incident.io, I would add that it involves running post-mortems, convenient automation of workflows tied to incidents, and creating tasks in Jira.
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.
Incident.io streamlines incident management with efficient features designed to enhance response strategies, allowing teams to handle disruptions with precision and control. It provides significant operational value, facilitating smoother resolutions.Incident.io focuses on transforming incident management through its intuitive approach and comprehensive toolset. Designed for experienced teams, it centralizes processes, enabling clear communication and structured workflow adjustments. By...
We are using incident.io for on-call purposes, specifically for alerting and phone calls. We have Grafana alerts, and when something fails or sends an alert, Grafana sends an alert message to our Slack, creates incidents on incident.io, and calls team members on the phone.
My main use case for incident.io is for incident creation, its postmortem, and the on-call feature of incident.io.
The main purpose of incident.io in my work is configuring the on-call team's response to incidents triggered by alerts. A specific example of how incident.io helped my on-call team respond quickly to an incident is that we set up a convenient schedule for responding to incidents. Incidents are tied to the criticality of alerts. We were able to conveniently build the on-call schedule thanks to the built-in functionality of incident.io and we successfully continue working with it. Regarding the main use of incident.io, I would add that it involves running post-mortems, convenient automation of workflows tied to incidents, and creating tasks in Jira.
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.