# incident.io vs Splunk On-Call: An Incident Management comparison for 2026
If you are comparing these two, there is a good chance you already use one of them, and it is probably Splunk On-Call. Maybe your team still calls it VictorOps. Maybe the login page still says "VictorOps is now Splunk On-Call!" and routes you to a victorops.com address, years after the rename. And maybe someone on your team has started asking whether the tool that pages you is still going anywhere.
That question is the heart of this comparison. **Splunk On-Call is a mature, reliable paging tool that has barely changed in years**, and it now belongs to Cisco by way of Splunk. It still does the core job well, it is cheap, and plenty of teams run it happily. **incident.io is a newer, fast-moving incident platform** built around Slack and Microsoft Teams, with its own on-call product, automatic timelines, call transcription, and an AI that investigates incidents.
[ad-uptime]
So this is less a head-to-head between equals and more a decision about whether to stay or move. If you are weighing that more broadly, our list of [Splunk On-Call alternatives](https://betterstack.com/community/comparisons/splunk-victorops-alternatives/) covers the wider field. This article goes deep on one option, what you would gain by moving to incident.io, what you would lose, and what it would cost.
## The short version
The table covers what teams leaving, or thinking about leaving, Splunk On-Call ask first. Product status matters as much as any feature row.
| Category | incident.io | Splunk On-Call |
|---|---|---|
| **What it is** | Slack-native incident response platform | On-call and alerting tool, formerly VictorOps |
| **Founded** | 2021, London | VictorOps founded 2012, acquired by Splunk in 2018 |
| **Owner** | Independent, venture-backed | Cisco, through Splunk |
| **Development pace** | Frequent releases, heavy AI investment | Maintenance mode, according to analysts and reviewers |
| **On-call scheduling** | ✔, add-on | ✔, core product |
| **Mobile app** | ✔ | ✔, well regarded |
| **Alert routing** | Alert routes and Catalog | Rules engine with transforms and routing keys |
| **Incident channel in Slack or Teams** | ✔, core design | Slack integration, not the core surface |
| **AI investigation** | ✔, Investigations | ✘ |
| **Responder suggestions** | Via Catalog and AI | ✔, machine learning suggestions |
| **Call transcription** | ✔, Scribe | ✘ |
| **MCP server** | ✔, hosted | ✘ |
| **Status pages** | ✔ | ✘ |
| **Post-incident reviews** | ✔, AI-drafted | ✔, basic |
| **Free plan** | Up to 5 users | ✘ |
| **List price** | $25 to $45 per user per month with on-call | From $5 per user per month for up to 10 users |
| **Collects logs, metrics, traces** | ✘ | ✘, separate Splunk Observability Cloud |
## Where each product stands in 2026
Most comparisons start with features. This one starts with trajectory, because the most important difference between these tools is which direction each one is moving.
### Splunk On-Call: still working, no longer growing
Splunk On-Call is the VictorOps engine with Splunk branding. It takes alerts from Splunk products and hundreds of third-party tools, runs them through a rules engine, routes them to on-call responders through schedules and escalation policies, and notifies them through a mobile app that reviewers still single out as one of the better ones at waking people up. Its status page shows the service running normally, and there is no end-of-life notice.
What has changed is the investment behind it. After Cisco completed its acquisition of Splunk in 2024, Constellation Research reported that Splunk had wound down the product and strategy teams for VictorOps, leaving engineering and support to maintain it. User reviews in 2026 describe long-standing bugs and a product that looks much as it did years ago. Splunk's newer incident response work goes into Incident Intelligence inside Splunk Observability Cloud and into its AI assistant tools, not into the standalone On-Call product.
None of that breaks your paging tomorrow. It does mean you should not expect Splunk On-Call to gain AI investigation, a modern Slack experience, or status pages.
### incident.io: built for the way teams run incidents now
incident.io was founded in 2021 by engineers who had run incidents at Monzo, and it raised a $62 million Series B in 2025. It treats the incident as a Slack or Teams channel. You type `/inc`, and it creates the channel, assigns an incident lead, announces the incident, and records everything that follows. The Catalog knows who owns the broken service, workflows fire as the incident changes, Scribe transcribes the call, and Investigations posts findings into the thread. Its on-call product, added later, handles the paging that Splunk On-Call does today.
| Product status | incident.io | Splunk On-Call |
|---|---|---|
| **Active development** | ✔ | Maintenance mode |
| **Where new investment goes** | This product | Splunk Observability Cloud and AI tools |
| **End-of-life notice** | ✘ | ✘, none announced |
| **Main surface** | Slack or Teams channel | Web portal and mobile app |
[summary]
### Move the telemetry and the paging together
If you are migrating off Splunk On-Call anyway, it is a good moment to ask whether paging should still sit in a different product from your logs and metrics. Better Stack imports your existing telemetry and runs on-call, incidents, and status pages in the same platform, so the migration reduces the number of tools you manage instead of swapping one for another.
**A migration is the cheapest time to consolidate, because you are rewiring the integrations anyway.** [See how importing works](https://betterstack.com).
[/summary]
## On-call and alert routing
This is the part of the job Splunk On-Call was built for, and it still does it well. If you move, on-call is what has to keep working from day one.
### Splunk On-Call: routing keys, rules, and a strong mobile app
Splunk On-Call covers rotations, overrides, and escalation policies, and it routes alerts with routing keys and a rules engine that can transform, annotate, and redirect incoming alerts before anyone is paged. The rules engine can attach runbooks, links, and dashboards so responders arrive with context, and machine learning suggests which responders have handled similar incidents. The mobile app is the part people miss most after they leave.
For a small team that just wants dependable paging, this is enough, and it has been for years.
### incident.io On-call: modern scheduling, billed as an add-on
incident.io On-call handles rotations, overrides, escalation paths, and do-not-disturb breakthrough on mobile, and it adds features Splunk On-Call does not have, including shadow rotations for new engineers, holiday calendars that flag conflicts, and on-call pay reporting. Alert routes group and filter incoming alerts, and the Catalog maps services to owning teams so routing follows ownership rather than a list of routing keys. Live call routing is available on Pro.
On-call costs $10 per user per month on Team and $20 on Pro with annual billing, charged only for people on rotation. If on-call is the only thing you are replacing, our guide to [on-call management alternatives](https://betterstack.com/community/comparisons/oncall-management-alternative/) compares incident.io with the other tools teams usually consider.
| On-call feature | incident.io | Splunk On-Call |
|---|---|---|
| **Rotations, overrides, escalation** | ✔ | ✔ |
| **Shadow rotations** | ✔ | ✘ |
| **Holiday conflict detection** | ✔ | ✘ |
| **On-call pay reporting** | ✔ | ✘ |
| **Alert transforms and annotations** | Alert route conditions | ✔, rules engine |
| **Responder suggestions** | Catalog ownership and AI | ✔, machine learning |
| **Routing model** | Service ownership in the Catalog | Routing keys |
| **Live call routing** | ✔, Pro and above | Limited |
| **Mobile app** | ✔ | ✔, a long-standing strength |
[summary]
### Page from the monitors you own
Splunk On-Call and incident.io both page on alerts sent in from other tools, so a broken integration or a misconfigured routing key can silently stop a page. Better Stack runs its own uptime monitors, log alerts, and metric thresholds and triggers its escalation policies directly, so detection and paging are one product. On-call is included in the $29 responder price.
**When the monitor and the pager are the same system, there is no routing key to get wrong.** [See Better Stack monitors](https://betterstack.com).
[/summary]
## Running the incident
This is where the gap between the two is widest. Splunk On-Call was designed to get the right person paged. incident.io was designed for everything that happens after.
### Splunk On-Call: a timeline and a war room
Splunk On-Call gives each incident a timeline and an audit trail, lets responders from different teams collaborate on it, and supports post-incident reviews with reporting on incident frequency, MTTA, and MTTR. Bidirectional integrations with ServiceNow and other ITSM tools keep tickets in sync. It is a solid incident hub, but most of the actual coordination tends to happen in Slack, Zoom, and a shared doc, outside the tool.
### incident.io: the incident runs in the channel
With incident.io, the Slack or Teams channel is the incident. Declaring creates the channel, sets roles, and posts announcements where stakeholders expect them. The incident lead gets nudged when updates are overdue, workflows page the right people as severity changes, and everything said and decided lands on the timeline without anyone taking notes. Scribe joins Zoom or Google Meet and writes down the key decisions, so people who join late can catch up without interrupting.
For teams used to Splunk On-Call, this is usually the biggest change. The coordination that used to live in five places ends up in one.
| Incident response | incident.io | Splunk On-Call |
|---|---|---|
| **Dedicated incident channel** | ✔, created automatically | ✘ |
| **Roles and update reminders** | ✔ | Limited |
| **Automatic timeline** | ✔, from channel activity | ✔, from incident actions |
| **Call transcription** | ✔, Scribe | ✘ |
| **Cross-team collaboration** | ✔ | ✔ |
| **ITSM sync** | ✔ | ✔, bidirectional |
## Automation
Splunk On-Call's automation lives in its rules engine, which works on alerts before they page anyone. incident.io's automation lives in workflows, which work on incidents once they exist.
The Splunk On-Call rules engine transforms and annotates alerts, sets routing, and attaches context such as runbook links. It is good at shaping the page. incident.io's workflows trigger on incident events, such as creation, severity changes, and status updates, and they page people, post updates, invite users, create Jira or Linear tickets, and set fields, with conditions that can use Catalog data. Pro adds custom incident types and customizable post-incident processes.
When you migrate, expect some of your Splunk On-Call rules to become alert-route conditions in incident.io and others to become workflows. It is worth auditing them first, since years of rules tend to include a few nobody remembers writing.
| Automation | incident.io | Splunk On-Call |
|---|---|---|
| **Alert transformation** | Alert route conditions | ✔, rules engine |
| **Incident workflows** | ✔ | ✘ |
| **Ticket creation** | ✔, Jira and Linear | ✔, via ITSM integrations |
| **Custom incident types** | ✔, Pro and above | ✘ |
## AI and MCP
This is where a maintained product and an actively developed one differ most. Splunk On-Call has not gained modern AI features, and Splunk's AI investment is going elsewhere in its portfolio.
incident.io launched Investigations in mid-2025. When an alert fires, it looks at telemetry from your connected tools, recent code changes, and similar past incidents, then posts hypotheses and evidence in the incident channel. In incident.io's own example of a payments outage, it proposes a fix and opens a pull request. It also names and summarizes incidents, suggests next steps, helps with triage, and drafts post-mortems, and a hosted MCP server lets Claude, Cursor, and other assistants read incidents, alerts, schedules, and catalog data. These features are included from the Team plan.
Splunk On-Call's intelligence is its machine learning responder suggestions and similar-incident matching. There is no AI investigation, no generated summaries, and no MCP server in the product.
| AI capability | incident.io | Splunk On-Call |
|---|---|---|
| **Root-cause investigation** | ✔, Investigations | ✘ |
| **Incident summaries** | ✔ | ✘ |
| **Drafted post-mortems** | ✔ | ✘ |
| **Responder suggestions** | ✔ | ✔, machine learning |
| **Call transcription** | ✔, Scribe | ✘ |
| **MCP server** | ✔, hosted | ✘ |
[summary]
### AI and MCP on top of the real data
incident.io's Investigations is a big step up from Splunk On-Call, but it still reasons over whatever your monitoring integrations expose. Better Stack's AI SRE and MCP server sit on the same platform that stores your logs, metrics, and traces, so the AI queries the raw data directly and returns a root cause with the evidence attached.
**If you are adding AI to incident response, give it direct access to the telemetry.** [See the AI SRE and MCP server](https://betterstack.com).
[/summary]
## Post-incident learning and status pages
Splunk On-Call supports post-incident reviews and reports on incident volume, MTTA, and MTTR, and those reports have not changed much in years. incident.io drafts post-mortems from the timeline, tracks follow-up actions, exports to your documentation tool, and on Pro adds advanced insights on incident trends and on-call load.
Status pages are a clean difference. Splunk On-Call has none, so most Splunk On-Call teams pay for a separate status page product. incident.io includes one public page on Team, an internal page on Pro, and unlimited and per-customer pages on Enterprise, all updated from the incident channel.
| Learning and communication | incident.io | Splunk On-Call |
|---|---|---|
| **Post-incident reviews** | ✔, AI-drafted | ✔ |
| **Follow-up tracking** | ✔ | Limited |
| **MTTA and MTTR reporting** | ✔ | ✔ |
| **Status pages** | ✔, from Team | ✘ |
| **Free viewers for stakeholders** | ✔ | Stakeholder visibility into incidents |
## What neither tool can see
Neither incident.io nor Splunk On-Call collects logs, stores metrics, records traces, or runs uptime checks as part of the product you are comparing. Splunk has a full observability suite, Splunk Observability Cloud, but it is a separate product with its own host-based pricing, and the on-call piece most tightly integrated with it is Incident Intelligence, not standalone Splunk On-Call.
So a team moving from Splunk On-Call to incident.io keeps whatever monitoring it already has, Splunk or otherwise, and responders keep switching to that tool to find the evidence behind an alert.
| Observability | incident.io | Splunk On-Call |
|---|---|---|
| **Logs, metrics, traces** | ✘ | ✘, separate Splunk Observability Cloud |
| **Uptime checks** | ✘ | ✘ |
| **Investigation data** | Connected integrations | Connected integrations |
## Pricing
Splunk On-Call is the cheapest name you are likely to see in this category, and for many teams that is the main reason they stay.
### Splunk On-Call
Splunk lists On-Call at $5 per user per month for up to 10 users, billed annually, with larger deployments quoted by sales. There is no free plan. The price covers on-call and incident handling, but not status pages or observability, which means buying separate products.
### incident.io
incident.io's plans are:
1. **Basic:** free for up to 5 users, with single-team on-call and one status page.
2. **Team:** $15 per user per month billed annually, or $19 monthly, with AI and multi-team on-call. On-call adds $10 per user per month.
3. **Pro:** $25 per user per month, adding advanced insights, custom incident types, and private incidents. On-call adds $20 per user per month.
4. **Enterprise:** custom, adding HIPAA, advanced access control, audit logs, and unlimited status pages.
### What a 25-person team pays
Assume 25 engineers who all respond to incidents, 10 of them on rotation, billed annually. Splunk's list price only covers the first 10 users, so the larger figure is an estimate. Monitoring is excluded for both.
| Cost component | Splunk On-Call | incident.io Team | incident.io Pro |
|---|---|---|---|
| **Seats** | Sales quote above 10 users, around $125 at the $5 list rate | 25 at $15, so $375 per month | 25 at $25, so $625 per month |
| **On-call** | Included | 10 at $10, so $100 per month | 10 at $20, so $200 per month |
| **Status pages** | Separate product | Included | Included |
| **AI** | ✘ | Included | Included |
| **Monthly total** | Around $125 plus a status page tool | Around $475 | Around $825 |
Staying on Splunk On-Call is clearly cheaper. Moving to incident.io costs a few hundred dollars more each month for this team, and in exchange you get an incident channel, AI investigation, transcription, status pages, and a product still being developed. Once you add a separate status page tool to the Splunk figure, the gap narrows further.
## Moving from Splunk On-Call to incident.io
If you decide to move, the migration is mostly about on-call, because that is what cannot break.
1. **Export schedules and escalation policies first.** Rebuild them in incident.io On-call and check them against Splunk On-Call for the next few weeks of shifts.
2. **Map routing keys to Catalog ownership.** Each routing key usually corresponds to a team or service. Moving that logic into the Catalog makes routing follow ownership instead of a list of keys.
3. **Audit your rules engine.** Decide which rules become alert-route conditions, which become workflows, and which can be deleted.
4. **Repoint integrations one at a time.** Send each monitoring source to incident.io while keeping Splunk On-Call as a fallback until you trust the new paging.
5. **Run both in parallel for at least one full rotation.** Only cancel Splunk On-Call once every schedule has paged correctly in incident.io.
Your Splunk contract is usually annual, so time the cutover for your renewal date to avoid paying twice.
## Which one fits your team
Stay on Splunk On-Call if paging is all you need and cost matters most. It is cheap, reliable, and familiar, and a team that runs incidents in Slack and a shared doc and does not want AI or status pages loses little by staying for another renewal. Just go in knowing the product is not being built out, and revisit the decision each year.
Move to incident.io if your incidents are growing in size and complexity, if you want AI to help find the cause, or if you are tired of piecing together Slack, Zoom, a doc, and a separate status page tool around your pager. It costs more, but it replaces several tools and is investing in exactly the areas Splunk On-Call is not.
If neither fits, our roundup of [incident.io alternatives](https://betterstack.com/community/comparisons/incident-io-alternative/) covers the other tools teams usually evaluate when leaving a legacy pager.
## Final thoughts
The honest trade-off is price against direction. **Splunk On-Call is cheap because it is finished**, a stable paging tool its owner has stopped growing, while incident.io charges more for a platform that keeps adding the coordination, AI, and communication features Splunk On-Call will not get.
So decide based on your time horizon, not this month's invoice. If you need dependable paging for one more year and nothing else, renew. **If you expect your incident process to look different in 2028 than it does today, start the migration while your current contract still gives you time**, and make sure the telemetry behind your alerts moves forward too, because neither tool collects it for you.
[summary]
### One assistant for the incident and the evidence
incident.io's MCP server exposes incidents, alerts, and schedules, and Splunk On-Call has no MCP server at all, but neither can give an AI assistant your logs or traces because neither stores them. Better Stack's MCP server covers the whole platform, so Claude or Cursor can query your logs with SQL, check who is on call, acknowledge an incident, and build a dashboard chart in the same conversation.
**With the incident and the telemetry behind one MCP endpoint, your assistant can investigate and respond without switching tools.** [Try Better Stack](https://betterstack.com).
[/summary]