I am currently working with Splunk Cloud, but I could review Splunk Enterprise as well because it is fundamentally the same product but with hosting being on-premises instead. Splunk Enterprise, Splunk Cloud, or Splunk ITSI (IT Service Intelligence) are all options we use. We are a customer of Splunk On-Call service. We use Splunk On-Call as an acknowledgment tool. It is not our primary ticketing solution for tickets; however, it creates tickets in Splunk On-Call. When we have priority one tickets assigned to us in ServiceNow, that is when we get the notification in Splunk On-Call to acknowledge that we have a priority one ticket in ServiceNow. We use it for the on-call part and we use the roster to schedule who is going to be on call. We also schedule and allocate who is the primary responder during office hours and during nighttime. We do use the on-call scheduling feature of Splunk On-Call. We are integrating Splunk On-Call directly with different back-end monitoring systems. First of all, you can initiate some of the alerts directly from monitoring tools, but our main primary integration is through Splunk IT Service Intelligence. That is where you have the backbone of the events being handled within IKEA. When you set the attribute that this event goes into the pipeline, you can say that this should be creating a ticket into ServiceNow or a Splunk On-Call acknowledgment as well. That integration has been developed, and it is very tight. Whenever you look at Splunk On-Call, which is the entry point on the acknowledgment, you will be able to see that it is coming from this monitoring system, and you have this associated ServiceNow ticket or associated Jira ticket. From there you can directly dive into runbooks to validate if this issue is still relevant or if it has been self-healing. We also have the bi-directional part that we are working on. Whenever a system is self-healing itself, Splunk On-Call acknowledgment will be closed by the system, and they will no longer be paging people based on something that has been solved. We have the acknowledgment part that we have discussed with Splunk On-Call. We have the escalation policies. We have the possibility to broadcast during daytime to as many responders as possible, so we get wide coverage with that. But also during nighttime, if it is just a single responder, we are sure that someone picks it up. We also have some built-in capabilities to see the reports and the assessment afterwards, in the form of post-mortem reports. We can see what happened during this time, who was involved, exactly who was paged and why they did not pick it up. We can see measurements of the mean time to acknowledge. Since it is not our primary responding primary ticketing system, we are not measuring mean time to recover, but we are working with that with the bi-directional integration. The report part is excellent for doing the follow-up on that aspect. It helps the organization both to have transparency and visibility of the current situation, but also transparency and visibility afterwards, regarding what went wrong or what went well.
Dev Ops Engineer at Data Elicit Solutions Pvt. Ltd.
Real User
Top 5
Mar 31, 2026
I have been using Splunk On-Call for nearly about two years. Our main use is incident alerting and on-call scheduling for our engineering and DevOps team. Basically, whenever something goes down, a service outage occurs, error rates spike, or deployments fail, Splunk On-Call routes the alerts to the right person at the right time. We also use it heavily for escalation policies. If the first person does not respond within a few minutes, then it is automatically paged to the next engineer in the chain.
Cloud Option Engineer at a tech vendor with 10,001+ employees
Real User
Top 5
Dec 5, 2025
I have been using Splunk On-Call for the last three years. My main use case for Splunk On-Call is incident alerting and real-time on-call management. It helps me to route critical alerts to the right teams, for example, the Telemetry team or backend DevOps team, and reduce the response times and ensure issues are acknowledged quickly. I also use it to automate on-call rotations and centralize incident communication. One notable scenario was when a production API started failing during peak hours. Splunk On-Call immediately routed the alert to the particular engineer, the DevOps engineer, triggered our escalation policy, and pulled the backend team to the response channel within minutes. This fast coordination helped me to restore the service much quicker than before.
We used it for on-call rotations. We used it to send alerts for monitoring. We also used it for escalation, so when we actually had an issue, it would find out who to call and call that person. It's deployed on-premises. About 200 people were using this solution in my organization.
IT Operation Manager at a tech services company with 501-1,000 employees
Real User
Dec 24, 2021
VictorOps is our alerting system for the on-call process. Our developers use this solution to be alerted when something goes wrong with our services. The solution is connected with our monitoring system.
Splunk On-Call offers seamless on-call scheduling and alert escalation with robust third-party integration, providing efficient incident management and resolution capabilities.Splunk On-Call facilitates effective IT alert management by delivering on-call scheduling, alert escalation, and comprehensive integration with monitoring systems. The platform's capabilities include smooth third-party interactions and the transmogrifier feature, which enhances message customization. Users benefit from...
I am currently working with Splunk Cloud, but I could review Splunk Enterprise as well because it is fundamentally the same product but with hosting being on-premises instead. Splunk Enterprise, Splunk Cloud, or Splunk ITSI (IT Service Intelligence) are all options we use. We are a customer of Splunk On-Call service. We use Splunk On-Call as an acknowledgment tool. It is not our primary ticketing solution for tickets; however, it creates tickets in Splunk On-Call. When we have priority one tickets assigned to us in ServiceNow, that is when we get the notification in Splunk On-Call to acknowledge that we have a priority one ticket in ServiceNow. We use it for the on-call part and we use the roster to schedule who is going to be on call. We also schedule and allocate who is the primary responder during office hours and during nighttime. We do use the on-call scheduling feature of Splunk On-Call. We are integrating Splunk On-Call directly with different back-end monitoring systems. First of all, you can initiate some of the alerts directly from monitoring tools, but our main primary integration is through Splunk IT Service Intelligence. That is where you have the backbone of the events being handled within IKEA. When you set the attribute that this event goes into the pipeline, you can say that this should be creating a ticket into ServiceNow or a Splunk On-Call acknowledgment as well. That integration has been developed, and it is very tight. Whenever you look at Splunk On-Call, which is the entry point on the acknowledgment, you will be able to see that it is coming from this monitoring system, and you have this associated ServiceNow ticket or associated Jira ticket. From there you can directly dive into runbooks to validate if this issue is still relevant or if it has been self-healing. We also have the bi-directional part that we are working on. Whenever a system is self-healing itself, Splunk On-Call acknowledgment will be closed by the system, and they will no longer be paging people based on something that has been solved. We have the acknowledgment part that we have discussed with Splunk On-Call. We have the escalation policies. We have the possibility to broadcast during daytime to as many responders as possible, so we get wide coverage with that. But also during nighttime, if it is just a single responder, we are sure that someone picks it up. We also have some built-in capabilities to see the reports and the assessment afterwards, in the form of post-mortem reports. We can see what happened during this time, who was involved, exactly who was paged and why they did not pick it up. We can see measurements of the mean time to acknowledge. Since it is not our primary responding primary ticketing system, we are not measuring mean time to recover, but we are working with that with the bi-directional integration. The report part is excellent for doing the follow-up on that aspect. It helps the organization both to have transparency and visibility of the current situation, but also transparency and visibility afterwards, regarding what went wrong or what went well.
I have been using Splunk On-Call for nearly about two years. Our main use is incident alerting and on-call scheduling for our engineering and DevOps team. Basically, whenever something goes down, a service outage occurs, error rates spike, or deployments fail, Splunk On-Call routes the alerts to the right person at the right time. We also use it heavily for escalation policies. If the first person does not respond within a few minutes, then it is automatically paged to the next engineer in the chain.
I have been using Splunk On-Call for the last three years. My main use case for Splunk On-Call is incident alerting and real-time on-call management. It helps me to route critical alerts to the right teams, for example, the Telemetry team or backend DevOps team, and reduce the response times and ensure issues are acknowledged quickly. I also use it to automate on-call rotations and centralize incident communication. One notable scenario was when a production API started failing during peak hours. Splunk On-Call immediately routed the alert to the particular engineer, the DevOps engineer, triggered our escalation policy, and pulled the backend team to the response channel within minutes. This fast coordination helped me to restore the service much quicker than before.
We used it for on-call rotations. We used it to send alerts for monitoring. We also used it for escalation, so when we actually had an issue, it would find out who to call and call that person. It's deployed on-premises. About 200 people were using this solution in my organization.
The solution is used to track, communicate, and escalate issues.
VictorOps is our alerting system for the on-call process. Our developers use this solution to be alerted when something goes wrong with our services. The solution is connected with our monitoring system.