Splunk ITSI Alternative: Open Source AIOps and AI Root Cause Analysis
Splunk ITSI is strong for Splunk-resident service KPIs but carries ingest licensing and is closed. Aurora is the open-source, multi-cloud alternative.
Key Takeaways
- Splunk IT Service Intelligence (ITSI) is a closed, proprietary AIOps add-on, not open source. It is purchased on top of Splunk Cloud Platform or Splunk Enterprise under either ingest-based or workload-based (Splunk Virtual Compute) pricing, with no public per-GB or per-seat dollar figure (Splunk ITSI pricing FAQ). Aurora by Arvo AI is Apache-2.0 open source with no ingest-priced licensing.
- ITSI is now Cisco-owned. Cisco completed its 28 billion dollar acquisition of Splunk on 18 March 2024, so ITSI roadmap and licensing now sit inside Cisco.
- ITSI is correlation and analytics centric. Its core jobs are service-oriented KPI dashboards, glass tables, predictive alerting, and grouping notable events into episodes via aggregation policies (Splunk ITSI product page). Aurora is an agentic investigator that actively queries clouds and runs commands.
- ITSI's newest AI is summarization and correlation, not autonomous execution. At .conf25 Splunk announced ITSI Event iQ (GA) for AI-driven alert correlation and ITSI Episode Summarization (Alpha). Aurora goes further: it runs kubectl, aws, az, and gcloud in sandboxed Kubernetes pods and can open pull requests (Aurora repo).
- Aurora is self-hosted, air-gapped capable, and multi-cloud. It supports AWS, Azure, GCP, OVH, and Scaleway, and runs on your own LLM via Ollama (Aurora repo). See our self-hosted AI SRE guide.
- Honest take: if your operational data already lives in Splunk, ITSI's glass-table service views and deep-dive analytics are hard to beat. The trade is Splunk-licensing cost and a closed, single-vendor stack.
If you already run Splunk, ITSI is one of the most capable service-monitoring layers on the market. The question this post answers is narrower: when does an open-source, self-hosted, multi-cloud AI SRE make more sense than another ingest-priced Splunk module? We compare ITSI and Aurora claim by claim, name where each genuinely wins, and cite every fact to a primary source.
For the broader category framing, see our guide on AI SRE vs AIOps. For the wider field of free root-cause tooling, see Top 10 AIOps platforms offering free root cause analysis.
What is Splunk ITSI?
Splunk IT Service Intelligence (ITSI) is a premium AIOps and service-monitoring application that runs on top of the Splunk platform. It models your environment as services and KPIs, then layers machine learning, dashboards, and event analytics on the telemetry you already ingest into Splunk.
Its core capabilities, per the official ITSI product page, include service-oriented dashboards that track KPIs and availability, service deep dives that let you analyze metrics in swim lanes and drill into raw data, predictive alerting that uses machine learning to detect future service degradations, automated event aggregation using out-of-the-box machine learning policies, and a KPI-driven triage view that prioritizes incidents by severity. ITSI also offers glass tables, which let teams visualize the key metrics behind a business or IT service.
ITSI's event analytics model is built around two concepts. A notable event is an anomalous incident detected by a multi-KPI alert, a correlation search, or an anomaly-detection algorithm. Notable events feed an aggregation engine that groups related events into episodes, which analysts triage, assign, and investigate in Episode Review. This correlation and grouping model is the heart of ITSI.
ITSI is now part of Cisco. Cisco completed its acquisition of Splunk for approximately 28 billion dollars on 18 March 2024, so ITSI's roadmap, support, and licensing now sit inside Cisco's observability portfolio.
What AI did Splunk announce for ITSI at .conf25?
At .conf25, Splunk announced two ITSI AI features focused on alert correlation and incident summarization, not autonomous investigation. Per the .conf25 observability recap, ITSI Event iQ became generally available and delivers AI-driven alert correlation that groups related alerts and highlights the incidents requiring immediate attention. ITSI Episode Summarization, announced in Alpha, uses AI to pull the key facts about an episode into a single AI-generated summary so analysts go from clicking through many tabs to seeing the relevant details in one place.
These are meaningful quality-of-life improvements for Splunk-resident teams. They are squarely in the correlate-and-summarize lane, though. Event iQ groups alerts; Episode Summarization writes a readable digest of what already happened. Neither runs a cloud API call, executes a kubectl command, or opens a fix. That gap is the opening for an agentic AI SRE.
What is Aurora?
Aurora is an open-source, Apache-2.0 AI SRE and incident-management platform from Arvo AI that autonomously investigates incidents across multi-cloud and Kubernetes environments. Where ITSI correlates and summarizes, Aurora actively gathers new evidence and can take remediation actions under human approval.
Aurora's agents are orchestrated with LangGraph. When an alert fires, they query AWS, Azure, GCP, OVH, and Scaleway plus Kubernetes, and they run kubectl, aws, az, and gcloud commands inside sandboxed Kubernetes pods to inspect live state. Aurora builds a Memgraph-backed infrastructure knowledge graph to reason about blast radius, generates root-cause analyses and postmortems that export to Confluence, Notion, or SharePoint, and can suggest code fixes or open pull requests. Destructive actions are human-gated.
Aurora ingests alerts via webhook from eleven monitoring connectors: PagerDuty, Datadog, Grafana, New Relic, OpsGenie, Netdata, Dynatrace, Coroot, ThousandEyes, BigPanda, and incident.io, plus a Slack bot for interaction. It is self-hosted and air-gapped capable, and it is bring-your-own-LLM through Ollama, so inference can stay inside your own boundary. For why that deployment posture matters to regulated buyers, see our self-hosted AI SRE guide.
Splunk ITSI vs Aurora: head to head
The cleanest way to see the difference is correlation versus investigation. ITSI is excellent at turning a firehose of Splunk-resident telemetry into service KPIs, glass-table views, and grouped episodes. Aurora is built to take a single incident and actively investigate it: query the cloud control plane, run live commands, map dependencies, and draft a fix.
| Dimension | Splunk ITSI | Aurora |
|---|---|---|
| License | Closed, proprietary Splunk premium app (pricing FAQ) | Apache-2.0 open source |
| Deployment | Add-on to Splunk Cloud Platform or Splunk Enterprise (pricing FAQ) | Self-hosted via Docker Compose or Helm, air-gapped capable |
| Multi-cloud scope | Analyzes whatever telemetry you ingest into Splunk | Native queries to AWS, Azure, GCP, OVH, Scaleway, Kubernetes |
| Investigation vs correlation | Correlates notable events into episodes, AI summarization in Alpha | Agentic, runs an LLM tool-calling loop to gather new evidence |
| Write and execute actions | Triggers ITSM tickets and playbooks; no native cloud-CLI execution | Runs kubectl, aws, az, gcloud in sandboxed pods, opens PRs, human-gated |
| Pricing model | Ingest-based or workload-based (SVC), no public rate (pricing FAQ) | Free and open source, you pay only your own compute and LLM |
| Self-host and air-gap | Self-managed Enterprise option exists; SaaS via Splunk Cloud | Self-hosted by default, BYO-LLM via Ollama |
| LLM model | AI features run inside the Splunk-managed stack | Bring your own model, including fully local |
Where the cost models diverge
The pricing difference is structural, not just a discount. ITSI is sold on top of Splunk under either ingest-based pricing, tied to GB ingested per day, or workload-based pricing measured in Splunk Virtual Compute units, and Splunk publishes no per-GB or per-seat rate on its pricing FAQ. In practice your ITSI cost scales with how much telemetry you push into Splunk. Aurora carries no licensing fee at all; it is Apache-2.0 and self-hosted, so your only costs are the compute you run it on and whatever LLM inference you choose, including a local model that costs nothing per token.
Where ITSI genuinely wins
ITSI is the stronger choice in several real situations, and it would be dishonest to pretend otherwise. If your operational data already lives in Splunk, ITSI sits directly on it with no extra pipeline, and its glass tables and service deep dives are a mature, polished way to present service health to both engineers and executives. Its episode and notable-event model is battle-tested for large enterprises that need a structured triage workflow with ITSM integration. And as a Cisco-owned commercial product, it ships with enterprise support and a long track record. If deep Splunk-resident analytics and executive-facing service views are the job, ITSI is hard to beat.
Where Aurora wins
Aurora wins when the job is active, cross-cloud investigation rather than Splunk-resident analytics. It is open source and self-hosted, so there is no ingest-priced licensing and no vendor lock-in, and it can run fully air-gapped with a local LLM. It is genuinely multi-cloud, querying AWS, Azure, GCP, OVH, and Scaleway directly rather than only reasoning over telemetry that has been shipped into one platform. And it executes: it runs cloud and Kubernetes commands in sandboxed pods, maps blast radius through a knowledge graph, and can open a pull request with a suggested fix, with destructive steps human-gated. For teams spread across providers, our multi-cloud incident management guide covers why that breadth matters.
A note on alert routing: Aurora complements, it does not replace
Aurora is an investigation layer, not an alert-routing or on-call-scheduling tool. It sits on top of whatever routing layer you run and consumes the alerts that layer forwards. ITSI handles its own event aggregation inside Splunk, but if you are assembling an open-source stack, Aurora pairs with a routing layer such as Keep, or with simple notification paths, rather than replacing your escalation tooling. Think of Aurora as the agent that investigates each incident after it has been routed, regardless of which router surfaced it.
Which should you choose?
Choose ITSI if your telemetry already lives in Splunk and your primary need is service-level KPI monitoring, glass-table dashboards, and structured episode triage, and you are comfortable with ingest-based or workload-based Splunk licensing and a closed, Cisco-owned stack. ITSI's depth on Splunk-resident data and its executive-facing service views are its strongest cards.
Choose Aurora if you want an open-source, self-hosted AI SRE that actively investigates and remediates across multiple clouds without ingest-priced licensing, if air-gapped or BYO-LLM deployment is a hard requirement, or if you specifically want an agent that executes cloud and Kubernetes commands and drafts fixes rather than one that correlates and summarizes. Many teams run both: a monitoring and correlation layer for service KPIs, and an agentic investigator on top for root-cause work.
For the category-level framing behind this decision, see AI SRE vs AIOps. For deployment-posture trade-offs, see self-hosted AI SRE, and for the wider tooling field, top 10 AIOps platforms offering free root cause analysis.