incident.io Alternatives: Open Source Incident Management 2026

No single open source project replaces incident.io. incident.io sells four products in one platform (on-call, Slack and Teams incident response, status pages, and an AI SRE called Investigations), and the open source alternatives each cover one layer: GoAlert for on-call, openstatus, Uptime Kuma, Gatus or Cachet for status pages, Incident Bot or openstatus for running incidents in Slack, Keep for alert management and workflows, and Aurora or HolmesGPT for AI investigation. Two of the best-known open source options are gone: Grafana OnCall OSS was archived on 2026-03-24 and Netflix Dispatch in September 2025. incident.io itself starts free, then $15 per user a month for Team and $25 for Pro, with on-call and Investigations priced on top.

Arvo AI builds Aurora. Aurora is an investigation agent: it takes an alert or an incident, queries your infrastructure and writes a root cause. It is not an incident response or on-call platform. It has no paging, no schedules, no escalation policies and no status pages, so it replaces only the Investigations part of incident.io, and it is built to run next to incident.io rather than instead of it. We could not install incident.io; every claim about it below links its own site or docs, read on 2026-10-21. Every repository was checked on GitHub the same day.

What does incident.io do, and how much does it cost?

incident.io calls itself a "software reliability platform unifying on-call, agentic root cause analysis, incident response, and status pages" (incident.io). Its pricing page on 2026-10-21:

Investigations (root cause analysis, the autonomous agent and Nexus data sources) is marked "Available as add-on" on Pro and Enterprise and has no published price. So for a 20-person team on Pro with on-call, the published part is ($25 + $20) x 20 = $900 a month before the AI SRE, which needs a quote. SOC 2 report and HIPAA are listed on every plan.

What is incident.io's AI SRE, and how does it work?

incident.io's AI SRE product is Investigations, "Agentic root cause analysis". Per the docs, the moment an incident is declared it gathers the alert and stack trace, similar past incidents, channel discussion, change events, runbooks, code changes and telemetry, then "forms a hypothesis and then tests it, reading your code and querying your dashboards to confirm or rule it out", and posts a root cause with evidence and next steps into the incident channel. Other points from its own pages:

• Model. It runs on Nexus, which incident.io calls its "production intelligence model", with its own instance per customer (Nexus). The underlying providers are OpenAI, Anthropic and Google Vertex under Zero Data Retention agreements (trust and safety).
• Your own model. Asked "Can we bring our own AI model or API key?", the docs answer "Not currently."
• Actions. "The only change Investigations can make to your systems is a pull request you review and merge yourself" (Investigations). The separate agent works in Slack, Teams, the mobile app, the web dashboard and coding agents.
• MCP. Nexus can be connected to Claude and Cursor over MCP (Nexus); MCP is listed on Team, Pro and Enterprise (pricing).
• Accuracy. incident.io grades each investigation on a closed incident against the cause your responders recorded, on a four-step scale from "Bullseye" to "Nowhere near", and shows the scores in your account (measuring accuracy). That is a sound way to judge it on your own incidents. We found no accuracy figure on its site that an outsider can rerun.

Is there an open source version of incident.io?

No. incident.io is a hosted service and its pricing page lists only hosted plans. The open source projects below are what you can run yourself; every one had commits in the three months before 2026-10-21.

What this adds up to: open source covers on-call (GoAlert) and status pages (four good options) well. Running an incident in Slack is thinner: Incident Bot is a small project and openstatus's incident features sit inside a status-page product. Nothing open source matches incident.io's workflows, catalog and insights. A full replacement means running three or four services and wiring them together, which is real work. Teams that pick it usually do so for data control, cost at headcount, or model choice, not to save effort.

Archived or stale projects to avoid starting on

• Grafana OnCall OSS. "On 2025-03-11 Grafana OnCall (OSS) entered maintenance mode and was archived on 2026-03-24" (README). Grafana points users to Grafana Cloud IRM, which is hosted. More in Grafana OnCall alternatives.
• Netflix Dispatch. Archived and read-only since September 2025; the README gave September 1, 2025 as the date (README).
• Monzo Response. Not archived, but the last commit is from 2021-06-08 (repo).
• LinkedIn Oncall and Iris. Not archived, but the last commits on their default branches are from 2025-08-20 and 2024-01-18 (Oncall, Iris).

Is Keep open source incident management and automation?

Keep describes itself as "The open-source AIOps and alert management platform" (GitHub): one place for alerts from many tools, with deduplication, enrichment, filtering and correlation, two-way integrations and workflows written in YAML, "Similar to GitHub Actions", that can query a database, update Jira or run Python (keephq.dev). It is not an on-call or status page tool, and it does not schedule people; it sits between your monitors and your paging and ticketing tools, and lists incident.io among its integrations.

Three things to know before you adopt it:

• Ownership. Elastic announced it would acquire Keep Alerting Ltd on 2025-05-07 and said "Keep will integrate with Elasticsearch and Kibana and remain open source" (Elastic). In November 2025 maintainer Shahar Glazner described Keep as being in a "community-maintained" phase where two maintainers review and merge community pull requests (issue 5451). Releases continue at that pace: v0.54.3 on 2026-09-09, last commit 2026-09-28.
• License. The core is MIT. Code in the ee/ folder is under the Keep Enterprise Edition license, which allows production use only under Keep's subscription terms (LICENSE).
• AI. The README lists AI backends for "Enrichments, Correlations and Incident Context Gathering", including OpenAI, Anthropic, Gemini, DeepSeek, Ollama and LlamaCPP. Keep's site marks its "Next-gen AIOps" alert correlation based on past incidents as "KEEP ENTERPRISE ONLY".

Keep groups and routes alerts; it does not investigate why one fired. Our Keep page covers its features, the open source versus Enterprise split, how active the project is after the Elastic deal, and where an investigation agent fits behind it.

How does incident.io's AI compare to an autonomous investigation agent?

Both start from an alert or incident and run their own queries. The differences are in where they run, who picks the model, and what you can check.

incident.io's advantage is context it already owns: your incident history, Slack channel, catalog and on-call data are in the same product, and its docs show it reading them. An agent you run yourself has to be given that context through connectors. The advantage of the open source agents is that you can read every tool call, choose and swap the model, keep everything inside your network, and test them before buying anything.

What the open source agents did on 19 real faults

We cannot run incident.io Investigations, so we tested what we could. We built a small app (an nginx frontend, a Python api, a worker, redis and a load generator) on a 3-node kind v0.33.0 cluster running Kubernetes v1.37.0, injected one known fault per scenario (two in scenario 12) and gave Aurora and HolmesGPT the alert; K8sGPT takes no alert and scanned the namespace. Each tool ran twice per scenario, 38 runs per tool. All three got the same admin kubeconfig, each behind its own guard (Aurora's observability_only command policy, HolmesGPT's allow-list, K8sGPT's read-only analyze). Aurora (commit 87d22baf) and HolmesGPT 0.43.0 both used bedrock/us.anthropic.claude-sonnet-5; K8sGPT 0.4.40 used us.anthropic.claude-sonnet-4-5, because Bedrock rejects the temperature parameter it sends to Sonnet 5. Aurora's runs are from 2026-10-02, HolmesGPT's and K8sGPT's from 2026-10-15 and 2026-10-16, on the same cluster and faults.

A judge model (us.anthropic.claude-opus-5-5) graded every answer against the injected fault. A person at Arvo read all 38 Aurora grades and changed none. The 76 HolmesGPT and K8sGPT grades are judge-model only: a second model re-read all 76 and agreed with every one, a third pass graded them from scratch and agreed on all 38 HolmesGPT verdicts while disputing 6 K8sGPT labels, and no person has checked them yet. A blinded regrade, with tool names removed from the judge's prompt, matched the published verdict in 38 of 38 Aurora runs, 37 of 38 HolmesGPT runs and 36 of 38 K8sGPT runs. The two agents' prompts differ in wording, and Arvo wrote the scenarios. The /benchmark page computes a two-sided Fisher exact test on the totals, p = 0.52, so the accuracy gap between Aurora and HolmesGPT is not significant, and it compares human-read grades with judge-only ones. HolmesGPT is about 3x faster at the median. K8sGPT lists what its analyzers flag in a namespace rather than investigating an alert, so it answers a different question; see HolmesGPT vs K8sGPT.

Scenario 13 shows the kind of answer you want posted into an incident channel. Every pod is Running and Ready, and a NetworkPolicy silently drops traffic from the api to redis. The alert was HighErrorRate [critical] namespace=shop service=frontend: 100% of requests to /api/ returned 5xx over the last 5 minutes (threshold 5%).

Aurora, run 1 (202 s, 25 tool calls, $0.69):

The root cause was a NetworkPolicy named redis in the shop namespace, created at 2026-10-02T20:23:54Z, which restricts ingress to redis:6379 to pods labeled app=worker only [20, 22]. The api pods are labeled app=api, not app=worker [23], so their connections to redis were silently dropped by the policy [...]

HolmesGPT, run 1 (110 s):

The api pods (api-f64486c4c-f7fpv, api-f64486c4c-nz5j6, label app=api) are not covered by this allow-list, so their connections to redis:6379 are now dropped by the policy.

Both agents got it in both runs; the fix is in the runbook NetworkPolicy blocking traffic. Where they failed: scenario 12 has two faults and the alert covers only a worker OOMKilled. Both agents found the OOM in both runs and missed that the frontend Service selected no pods, and Aurora wrote that the frontend "remained healthy and unaffected" with pod status as its only evidence. The checks that catch it are in a second fault the alert does not cover. Every transcript and grade is on /benchmark.

How does Aurora work with incident.io?

Aurora's incident.io connector is in the open source repo, so this is what the code does, not a plan:

1. Connect with an incident.io API key. Aurora checks the key's roles. Posting results back needs incident_editor for incident updates or on_call_editor for alert notes.
2. Point an incident.io webhook at Aurora. Aurora checks incident.io's webhook signature once you save the signing secret; until you do, it accepts unsigned events, so save it. New incidents (public and private) start an investigation, and so do new alerts unless you switch alert RCA off, which helps orgs whose alerts fire constantly. For alerts only, a minimum priority or an allow-list, ranked against your org's own alert priorities, keeps low-priority noise out; declared incidents are not filtered.
3. Aurora investigates with its other connectors (cloud accounts, Kubernetes, monitoring, code) and with three read-only incident.io tools: list incidents, get one incident, read its timeline. Its instructions tell it to check past closed incidents for repeats.
4. The result goes back to incident.io when post-back is on (it is off by default). At completion, Aurora posts one update on the incident's timeline headed "Aurora RCA", with the root cause, impact, a link to the full investigation and the line "Generated automatically by Aurora. Verify before acting." If the alert never became an incident, the RCA goes on the alert as a note instead. When several alerts are grouped, the first RCA becomes the group's note, later alerts add a short correlation note instead of a full report, and the group note is extended if a later RCA finds something new.
5. Slack. If you add Aurora's Slack app to incident.io's incident channels, it can answer @mentions there.

So incident.io keeps paging, roles, comms, status pages and the post-incident process, and Aurora adds an investigation your team can read, rerun and run on your own model. The overlap is the root cause step: if you already pay for Investigations, run both on the same incidents for a few weeks and compare. If you run Keep or another alert hub instead, Aurora takes alerts from PagerDuty, Datadog, Grafana, New Relic, OpsGenie and more (README).

We have not measured Aurora inside incident.io the way we measured it in the lab: the 19 scenarios fed the alert straight to each agent.

Which incident management tools let me bring my own AI model?

If the requirement is that incident data never reaches an AI vendor at all, the on-call layer is the easy part: GoAlert, Uptime Kuma and Gatus describe no AI features and run on your servers. For investigation, Aurora and HolmesGPT with a local model through Ollama keep everything inside your network. Our lab used a frontier model on Bedrock; we have not tested local models.

How do I compare open source and commercial incident management tools?

Split the job into layers first, then compare per layer. A tool that is excellent at one is usually thin at the others.

1. On-call and paging. Delivery is the requirement. incident.io claims "Millions of alerts delivered with 99.99% reliability" (on-call); with a self-hosted tool such as GoAlert, keeping paging up is your job. Rootly's on-call is another $20 per user a month on top of its $20 Incident Response (pricing).
2. Response workflow. Roles, severities, channels, updates, follow-ups. This is incident.io's strongest layer and open source's weakest.
3. Status pages. Open source is strong here. incident.io's Basic includes one public page; internal pages start on Pro and customer pages need Enterprise.
4. Postmortems. incident.io's AI post-mortem editor is on Pro and above. Incident Bot builds a postmortem document base; Aurora generates postmortems from its investigation and exports them to Confluence, Notion or SharePoint.
5. Investigation. Ask every vendor for accuracy on faults they did not choose. Ours are public: clone Arvo-AI/aurora-lab, break a scenario, give a trial agent the alert line from its scenario.yaml, and compare the answer with the must_identify list in the same file. To diagnose one failure on your own cluster, /diagnose walks through it.

Then check the boring things: is the repository still maintained (two of the best-known ones are archived), which license applies to the parts you need (Keep's ee/ folder, Cachet's custom license, openstatus's AGPL if you modify and host it), and who carries the pager for the incident tool itself.

For commercial head-to-heads see incident.io vs Rootly and FireHydrant vs incident.io; for the wider open source picture, open source incident management and open source AI SRE tools compared.

What this comparison does not cover

We did not test incident.io, Rootly, Keep, GoAlert or the status page tools; their rows are what their own pages and repositories say. The lab is Kubernetes-only, synthetic, and the faults are ours. HolmesGPT 0.44 and 0.45 were already out when we ran 0.43.0, and K8sGPT 0.4.41 shipped on 2026-10-21, so their current versions are untested. Aurora's $0.35 median is model cost only; you also run the servers.

Verified 2026-10-21: incident.io pricing, Investigations, Nexus, agent and on-call pages and docs; Rootly pricing; Elastic's Keep announcement; every GitHub repository linked (license, latest release, last commit, archive status); Aurora's incident.io connector in the Aurora repo; lab numbers from results.json generated 2026-10-21.

Aurora is on GitHub under Apache 2.0, or book a demo to see it investigate your incident.io incidents.