Grafana OnCall OSS Archived: Alternatives, Fork, IRM Pricing

Grafana OnCall OSS is archived. It entered maintenance mode on 2025-03-11 and was archived on 2026-03-24, the date Grafana set for its Cloud Connection to stop working with self-hosted installs, which ends mobile push and Grafana-relayed SMS and phone calls (Grafana). Grafana recommends Grafana Cloud IRM instead: it is cloud-only and free for 3 active IRM users a month; on Pro, the $19 monthly Grafana Cloud platform fee includes 3 active IRM users and each further one starts at $20 (pricing). If you need to stay self-hosted and open source, the realistic options are the Appwrite-maintained fork of OnCall and GoAlert, with ntfy for push and your own Twilio account for calls and SMS.

Everything below was checked on 2026-10-21 against each project's repository or each vendor's own pages. Arvo AI builds Aurora SRE, which appears near the end. Aurora is not a pager: it does not schedule, page or escalate, so it is not on the list of OnCall replacements. It investigates the alert after the page, and that is the one part of this page we measured ourselves.

What happened to Grafana OnCall OSS?

Two dates float around for the archival. The README says "On 2025-03-11 Grafana OnCall (OSS) entered maintenance mode and was archived on 2026-03-24", and the last commit is from 2026-03-24. The read-only flag on GitHub was set on 2026-06-05. For planning, 2026-03-24 is the date that matters: it is the date Grafana gave for its APIs and Cloud Connection to stop serving OnCall OSS.

The old OSS documentation page at grafana.com/docs/oncall/latest/set-up/open-source/ now redirects to the Grafana IRM docs, so links to it in older articles land on a different page.

Can you still self-host Grafana OnCall OSS?

Yes, but you own it. Grafana says "you will be able to use any current deployment of OnCall (OSS) indefinitely", and the code is still AGPLv3 (3,881 stars, 438 forks on 2026-10-21). What stopped on 2026-03-24:

• Mobile app push. It went through Grafana's Cloud Connection. Grafana's migration guide says mobile push, SMS and phone notifications from Cloud Connection are not available to OSS users after archival (migration guide).
• Grafana-relayed SMS and phone calls. Grafana's suggestion is to configure Twilio, Exotel or Zvonok yourself, or trigger your own call and SMS workflows with webhooks (Grafana blog).
• Security fixes. The CVE fixes were a maintenance-mode promise for the year before archival. The last release is v1.16.11 from 2026-02-11.

For push, Grafana merged outgoing webhooks in personal notification rules before archival, which "makes it possible to use third-party services like Pushover, Gotify, or ntfy to continue receiving push notifications" (Grafana blog).

Is there a maintained Grafana OnCall fork?

One fork of the GitHub repository shows steady work: appwrite/grafana-oncall, "Appwrite's fork of Grafana OnCall" (AGPL-3.0). Its README says Appwrite "maintains this fork for its own use". As of 2026-10-21:

• Latest release v1.24.10 (2026-09-21), after more than 25 releases since mid-August 2026, and dependency updates merged since then.
• It runs on Grafana 13.2 and React 19 ("Upstream's plugin crashes on mount there"), and on Django 5.2 LTS instead of upstream's 4.2.
• It adds a Discord integration and SMS through MSG91 alongside Twilio, Zvonok and Exotel.
• Signed container images, SBOMs and build provenance at ghcr.io/appwrite/grafana-oncall.

Its README also lists what it does not offer: "No support and no roadmap. We keep it working for our own use." The plugin is unsigned, so Grafana needs GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=grafana-oncall-app (the setting takes plugin IDs, so list only this one, and pin the signed image by digest); the Helm chart is not published to a chart repository; and "The mobile app does not work. It relied on Grafana Cloud's push relay." The other direct forks of the repository had one star or fewer on 2026-10-21. Grafana said in 2025 that if the community forks OnCall, "we will support them with best reasonable effort."

Our view: the Appwrite fork is the shortest path if you are on OnCall OSS today and your Grafana upgrade broke the plugin. It is one company's fork for its own use, so treat it as a bridge and keep your Terraform or API export current.

Is Grafana IRM open source or self-hosted?

No. "Grafana IRM is the on-call management and incident response product in Grafana Cloud", and the docs call it "a paid Grafana Cloud add-on, billed based on monthly active IRM users" (docs). There is no self-managed or open source IRM. Grafana's only self-hosted on-call product was OnCall OSS, and that is the archived one.

Source: grafana.com/pricing, 2026-10-21. The $19 is the one Pro platform fee for the whole Grafana Cloud stack (the same fee appears on every product's card), not an extra IRM charge. So a team of 3 on-call engineers on Pro pays $19 a month, and a team of 8 starts at $19 plus 5 x $20 = $119 a month before volume discounts. An active IRM user is "a user who is included in OnCall schedules or escalation chains" or who changed an alert group's status or OnCall configuration, received or sent a page, or created or edited an incident in the month. The IRM product page puts it as billing "for people who are on call, get notified, or take action that month" (IRM).

IRM notifies through the mobile app, Slack, Microsoft Teams, Telegram, SMS, phone and email, and the same page says it "also covers incident coordination, post-incident review templates, and AI investigations through Grafana Assistant".

Migrating from OSS. Grafana's guide offers Terraform or the OnCall API, and notes "The IRM migration tools don't currently support Grafana OnCall OSS as a source platform." Move resources in order: integrations, escalation chains, routes, then schedules (migration guide).

Should you consolidate on-call into Grafana IRM instead of a separate tool?

Yes, if your alerts and dashboards already live in Grafana Cloud and you can send alert data to a SaaS. Alert rules, routing, schedules and incidents then share one stack, and you pay only for people who are actually on call. No, if you self-host Grafana for data-residency or air-gap reasons: IRM requires Grafana Cloud, and moving paging there means your alert payloads leave your network. In that case a self-hosted pager (GoAlert or the Appwrite fork) next to self-hosted Grafana keeps the boundary where it was. A third case: if you already pay for PagerDuty or incident.io, Grafana Alerting can keep sending to them, and adding IRM only makes sense if you plan to drop the other tool.

What are the Grafana OnCall alternatives?

Checked 2026-10-21. Prices are list prices from each vendor's pricing page.

Notes on the ones a self-hoster is most likely to pick:

GoAlert is the closest open source match to what OnCall did. It sends "SMS and Voice using Twilio, email using Mailgun, or Slack", and takes alerts from its generic API, email, Grafana, Prometheus, Site24x7 or Sensu (goalert.me). The only hard requirement is a Postgres database (getting started). You bring the Twilio account, as with OnCall OSS after archival. It does not have OnCall's Grafana-plugin UI.

Keep is not a pager. A Keep team member who describes himself as the "creator of OnCall (not related to Grafana anymore)" wrote in March 2025 that Keep is a "toolbox for alerts" and "If you want to send SMS and make Phone Calls to your on-call engineers, you still need some 3'rd party", suggesting Keep plus Twilio, or "minimalistic use of PagerDuty (Just calendar and phone calling)" alongside Keep (discussion). Elastic agreed to acquire Keep in May 2025 and said it "will integrate with Elasticsearch and Kibana and remain open source" (Elastic).

PagerDuty's free plan covers 5 users, "1 on-call schedule, 1 escalation policy", with "100 free global SMS or phone notifications per month"; Professional removes the cap. For small teams leaving Opsgenie as well as OnCall, that, incident.io's Basic plan (single-team on-call included) and Grafana IRM's free tier (3 active users) are the cheapest hosted starting points we found.

For incident management beyond paging, see open source incident management and the Opsgenie guide.

Which on-call tool doesn't send incident data to an AI vendor?

A self-hosted pager with no AI features: GoAlert, the Appwrite fork or LinkedIn Oncall. Alert payloads then stay on your servers, apart from what you send to Twilio, Slack or a push service for delivery. The hosted tools now bundle AI: Grafana IRM lists "AI investigations through Grafana Assistant", and incident.io and Rootly list AI features on their pricing pages. Check each vendor's data-processing terms for the plan you buy; the pricing pages do not settle it.

If you want AI investigation without sending data to a model vendor, run the investigation agent yourself with a local model. Aurora supports Ollama for air-gapped operation, and HolmesGPT documents Ollama too.

What happens after the page: where an investigation agent fits

Every tool above answers "who gets woken up". None of them tells that person why the alert fired. That second step is where an AI investigation agent sits, and it runs beside the pager, not instead of it.

With Grafana Alerting it is one more contact point. Aurora's Grafana connector is a webhook contact point ("No API key required") that you add to a notification policy, for Grafana Cloud or self-hosted Grafana. The same policy keeps paging through IRM, GoAlert, PagerDuty or a fork. Aurora also takes alerts from PagerDuty, Datadog, New Relic, OpsGenie, incident.io and others. If you are on Grafana Cloud, Grafana Assistant Investigations does this step inside Grafana and can be started from IRM webhooks (docs); it is "Not available in self-managed deployments" (docs).

What we measured on that step

We ran the step after the page in a lab: a small app (shop: nginx frontend, Python api, worker, redis, load generator) on a 3-node kind v0.33.0 cluster with Kubernetes v1.37.0, 19 injected faults, 2 runs each. Each run started from alert text of the kind a pager delivers, for example "HighErrorRate [critical] namespace=shop service=frontend: 100% of requests to /api/ returned 5xx over the last 5 minutes (threshold 5%)." No pager was in the loop: the lab posted the alert to Aurora's API directly.

From results.json. A judge model (Claude Opus 5.5) graded every answer. A person at Arvo AI 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, a third pass disputed 6 K8sGPT labels, and a blinded regrade matched 38 of 38, 37 of 38 and 36 of 38). The prompts differ in wording. Aurora and HolmesGPT ran Claude Sonnet 5 on Bedrock; K8sGPT ran Claude Sonnet 4.5, because Bedrock rejects the temperature parameter K8sGPT sends for Sonnet 5. All three got the same admin kubeconfig behind their own guard (Aurora's observability_only command policy, HolmesGPT's allow-list, K8sGPT's read-only analyze). Aurora ran on 2026-10-02; HolmesGPT and K8sGPT on 2026-10-15 and 2026-10-16, same cluster and faults. Arvo AI wrote the scenarios and builds Aurora. Aurora and HolmesGPT are roughly even on accuracy (the two-sided Fisher test on /benchmark gives p = 0.52, comparing person-read with judge-only grades), and HolmesGPT is about 3x faster. K8sGPT does a different job: it lists what its analyzers detect rather than investigating an alert. Full table and traces: /benchmark.

A page that says nothing useful. In scenario 13 the alert only says the frontend returns 100% 5xx; every pod is Running. Aurora's first run took 202 seconds and 25 tool calls ($0.69) and wrote:

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

The bracketed numbers point at the commands whose output supports each claim (run folder). The second run was also correct but took 444 seconds. HolmesGPT got it right in 110 and 118 seconds. K8sGPT printed "No problems detected" both times, because no object looks broken. The manual checks are in the NetworkPolicy blocking traffic runbook.

Where it went wrong. In scenario 12 the alert is a crash loop on the worker, which is being OOMKilled, while, separately, the frontend Service selects no pods. Both Aurora runs found the OOM and then stated the opposite of the truth about the rest. The first run wrote:

Other workloads in the shop namespace (api, frontend) remained healthy and unaffected [5, 14].

The second said the api and frontend pods "were running normally and unaffected" (run folder).

HolmesGPT was partial on both runs too. An agent that starts from the alert tends to stay inside the alert. Whoever takes the page should still check what the alert does not mention; the second fault runbook lists the checks.

The lab is Kubernetes-only and synthetic, with faults we wrote, so treat it as a method rather than a forecast. Every scenario ships with its alert and its expected findings in Arvo-AI/aurora-lab, so you can run any agent through the same faults. For one failure on your own cluster, use /diagnose. For more on the agents themselves, see Aurora vs HolmesGPT vs K8sGPT and AI incident investigation tools compared.

Which should you choose?

Verified 2026-10-21: Grafana blog, docs, pricing and IRM pages; GitHub repositories, releases and star counts as linked; PagerDuty, incident.io and Rootly pricing pages; Atlassian's Opsgenie migration page; Elastic's Keep announcement. Lab numbers from results.json, generated 2026-10-21.

Aurora is open source on GitHub (Apache 2.0); to see it investigate your Grafana alerts, book a demo.