Splunk On-Call (VictorOps) is gone — what Slack teams should use instead
Published May 25, 2026 · A practical migration guide for engineering teams still sorting out life after VictorOps.
The short version
What Cisco / Splunk announced
Cisco completed its acquisition of Splunk in March 2024. Within months, the combined company announced that Splunk On-Call — originally built by VictorOps before Splunk acquired VictorOps in 2018 — would be retired. The product reached end of life on March 31, 2025.
Customers on active contracts were encouraged to migrate to Splunk Observability Cloud, which incorporates alerting and some on-call capabilities. Teams that wanted a third-party path were largely left to find their own way. The result: a lot of teams scrambled into emergency migrations in Q1 2025, some landed on tools that were the wrong fit, and many are now reassessing.
If you're reading this more than a year after the shutdown, you're not alone. Some teams are still running on expired contract extensions, cobbled-together workarounds, or a tool they chose in a hurry and are now reconsidering. This guide is written for all three situations.
Why Splunk Observability Cloud isn't automatically the answer
Splunk Observability Cloud is, at its core, a metrics, distributed tracing, and APM platform. It can send alerts and has incorporated some on-call routing functionality, but that's not what it was designed around — and it shows.
If your organization already runs Splunk Observability Cloud for infrastructure monitoring and genuinely needs the alerting integration tight-coupled to your metrics, adding the on-call routing there can make sense. But if you're a team that used VictorOps mostly to schedule rotations and get paged in Slack, you're being pointed toward a full observability platform when what you need is a rotation scheduler.
Buying Splunk Observability Cloud for its on-call features alone is roughly equivalent to buying a monitoring platform because it also has a calendar widget. The cost and complexity are out of proportion to the problem.
Be honest about what you actually used Splunk On-Call for
VictorOps / Splunk On-Call covered a wide surface area, but most teams we talk to were primarily using one of three things:
- Rotation scheduling. Defining who is on-call when — weekly rotations, daily handoffs, follow-the-sun coverage, holiday overrides, and a live answer to "who is on-call right now?"
- Slack notifications. Pinging the on-call person in a Slack channel, keeping a Slack user group like
@oncallcurrent, and sending handoff reminders so the incoming responder knows they're up. - Full incident management. Phone and SMS escalation chains, multi-tier escalation policies, bi-directional integrations with dozens of alert sources, incident timelines, and postmortems.
Buckets (1) and (2) are a rotation problem. Bucket (3) is an incident management problem. These require very different tools, and the distinction matters a lot for cost and complexity. The answer to "what should we migrate to?" depends almost entirely on which bucket describes your real usage.
The realistic alternatives, ranked by team profile
If you're a Slack-first team that mainly needed rotations → Sched
Sched is a Slack-native rotation manager built specifically for engineering teams that coordinate on-call in Slack. It runs your rotations, syncs a Slack user group with whoever is currently on-call, sends handoff messages, and lets people swap shifts directly from Slack.
- Flat pricing: free for up to 3 schedules, $9.99 per workspace per month for unlimited.
- No per-seat pricing — adding more people to a rotation doesn't change your bill.
- Setup takes minutes; there's no separate web UI to onboard your team into.
- Best fit for teams up to ~200 engineers with 1–50 rotation schedules.
Trade-off: Sched is deliberately narrow in scope. If you relied on Splunk On-Call for phone/SMS escalation, complex multi-tier escalation policies, or deep integrations with alert aggregators, you'll need to either pair Sched with a separate alerting tool or look at one of the fuller-featured platforms below.
If you genuinely need full incident management → PagerDuty, Incident.io, or FireHydrant
PagerDuty is the closest like-for-like replacement for the full Splunk On-Call feature set: rotation scheduling, escalation policies, phone and SMS alerting, hundreds of monitoring integrations, mobile app, postmortems. It is also the most expensive option.
Incident.io and FireHydrant are newer entrants that lean more heavily into Slack-native incident workflows and postmortem tooling. Both include on-call functionality alongside broader incident management features. Either can be a good fit if you want something that feels more modern than PagerDuty and are willing to pay accordingly.
Don't pick one of these because it's the enterprise-safe choice. Pick it because you actually use the escalation chains, status pages, and postmortem workflows — otherwise you're paying for a lot of features you'll ignore.
If you're already running Splunk Observability Cloud → add a dedicated on-call tool alongside it
If your organization is paying for Splunk Observability Cloud anyway — for APM, infrastructure monitoring, or log management — it may make sense to use its alerting rules as the trigger layer and route those alerts to a dedicated on-call tool for rotation management and paging. This is broadly what Atlassian recommended for Splunk shop customers who wanted a clean separation of concerns.
In practice this means Splunk handles the metrics and fires the alert; a tool like Sched, PagerDuty, or Incident.io handles the "who gets paged and when" logic. It's more moving parts than a single platform, but it avoids being locked into on-call tooling that's bundled inside a platform you might not keep forever.
A simple decision tree
1. Did you use Splunk On-Call mainly to schedule rotations and notify people in Slack?
→ Yes: Move to a Slack-native rotation tool like Sched. You don't need an observability platform or a full incident management suite.
2. Do you need phone/SMS escalation, multi-tier escalation policies, or deep integrations with alert aggregators like Datadog, PagerTree, or a home-grown webhook pipeline?
→ Yes: Look at PagerDuty or Incident.io. Compare total cost per active responder at your team's headcount, not just the list price.
3. Is your company already running Splunk Observability Cloud for monitoring and paying for it regardless?
→ Yes: Use it for alert routing. Add a dedicated on-call rotation tool alongside it rather than trying to make it do both jobs well.
How to migrate cleanly (even if you missed the deadline)
Some teams ran a clean migration before March 2025. Others scrambled into the first available tool. If you're re-evaluating a hasty migration, this process applies either way:
- Audit what you actually have running today. Write down your current rotations: cadence, participants, any overrides or coverage gaps. If you migrated in a hurry, there are likely rotations that were recreated incorrectly or aren't being maintained.
- Map your alert sources. Every system that currently fires an on-call page — monitoring tools, custom webhooks, CI/CD pipelines — needs to be accounted for. Missed alert paths are the most common failure mode in on-call migrations.
- Run the new tool in parallel before cutting over. Even if you're already on a replacement tool, running a candidate side-by-side for a sprint or two lets you catch discrepancies: rotations that fire at the wrong time, user group assignments that didn't carry over, or participants who dropped off.
- Cut over deliberately, not on a Friday. Switch your alert routing on a Monday morning. Give yourself a full week of business hours to catch anything that misbehaves before the weekend. Keep read access to your old configuration for at least 30 days.
- Document the new setup. On-call configuration is often tribal knowledge. Write down what you have and where it lives. The next time something changes — and it will — you'll want a record of what was intentional.
FAQ
When did Splunk On-Call shut down?
Splunk On-Call reached end of life on March 31, 2025. Cisco completed its acquisition of Splunk in March 2024 and the retirement was announced shortly after. If you're still seeing the product in your stack — via a contract extension, a legacy integration, or a webhook that nobody turned off — the underlying service is no longer supported and you should treat it as a live incident waiting to happen.
What is the best Splunk On-Call alternative for Slack teams?
It depends on what you were actually using it for. If your team used VictorOps to define who is on-call and make sure Slack knew about it, a Slack-native rotation tool like Sched is the most direct replacement — and it's a fraction of the cost and complexity of a full incident management platform. If you relied on phone escalation chains or hundreds of alert source integrations, look at PagerDuty or Incident.io instead.
Is Splunk Observability Cloud a replacement for On-Call?
Only in the sense that it includes some alerting and on-call routing capabilities. Splunk Observability Cloud is, first and foremost, a metrics and APM platform. Its on-call features are not the product's primary design goal, and teams that used VictorOps purely for rotations and Slack paging will find it to be significant overkill. It may make sense if your organization is already running Splunk Observability Cloud for monitoring and wants a single vendor, but it's not a standalone on-call replacement.
Do I have to switch to PagerDuty?
No. PagerDuty is the most established like-for-like replacement and handles the full VictorOps feature set well. But it is also expensive and complex, and most teams that used Splunk On-Call for basic rotation scheduling and Slack notifications don't need that complexity. Evaluate PagerDuty if you have multi-tier escalation chains, a requirement for phone/SMS paging, or a large library of custom alert source integrations. Otherwise, a simpler and cheaper tool will get you 90% of the way there.
You can install Sched in your Slack workspace and run up to 3 rotation schedules free — no credit card required.