Grafana OnCall is archived: what self-hosted users should do next

Grafana OnCall OSS is done. The project entered maintenance mode on 2025-03-11 and the repository was archived on 2026-03-24. No more releases, no more bug fixes, no more security patches. Grafana’s recommended path forward is Grafana Cloud IRM, their hosted incident response product.

Credit where it’s due: OnCall OSS was a genuinely good piece of software. It gave teams real escalation chains, rotations, and Slack/Telegram paging without a per-seat bill, and for a few years it was one of the best answers to “how do we do on-call without paying enterprise prices”. That’s exactly why its archival stings - a lot of teams built their paging on it.

If yours is one of them, this post is the practical version of what to do next.

Your install still runs. That’s the trap.

Nothing broke on archival day, which makes it easy to ignore. But three clocks are now ticking:

Security patches have stopped. OnCall receives webhooks from the internet and holds phone numbers, schedules, and escalation logic. Running an unpatched copy gets riskier every month. The next CVE in a dependency is your problem now, permanently.

Compatibility drift. OnCall runs as a Grafana plugin plus a backend stack (Django, Celery, Redis/RabbitMQ, MySQL/Postgres). Every Grafana upgrade is a gamble on whether the archived plugin still loads. Most teams end up pinning Grafana itself - which freezes your whole observability stack, not just the pager.

Cloud-dependent notification paths. Mobile push, SMS, and phone calls in OSS OnCall were delivered through a connected Grafana Cloud account, not by your self-hosted install. Those paths ran on borrowed infrastructure, and an archived project has no claim on their future. If your 3 AM page arrives by phone, that path deserves the least trust.

The failure mode isn’t dramatic. It’s a page that doesn’t arrive during an incident, eighteen months from now, on infrastructure nobody has touched since 2026.

The honest list of options

1. Do nothing and pin everything. Legitimate for a while. Freeze the OnCall version, freeze Grafana, firewall the webhook endpoints, and accept that you are now the maintainer of record. This buys time; it isn’t a destination.

2. Follow Grafana to Cloud IRM. The official path, and the least migration effort if your alerting is deeply Grafana-native. It’s a hosted product with per-user pricing, so the thing that made OnCall OSS attractive - free, self-hosted, no seats - is exactly what you give up.

3. Move to another self-hosted alert router. Keeps the self-hosted property, but re-runs the same risk: you’re betting your paging on another project’s continued goodwill, and you keep maintaining a Django-or-equivalent stack whose only job is deciding who to wake up.

4. Ask whether the stack under it still earns its keep. OnCall existed to route alerts produced by the rest of a DIY pile: metrics store, exporters, alert rules, dashboards, and a router on top, each needing its own config and care. If a team of four is honest about the hours that stack costs, archival of one layer is a reasonable moment to retire the pile, not just replace the layer.

AlertKick was built for that fourth option. Consider the rest of this post an opinionated take and weigh it accordingly.

What AlertKick replaces (and what it doesn’t)

AlertKick is not a drop-in OnCall replacement that routes alerts from your existing Prometheus rules. It replaces the stack: one agent handles monitoring (infrastructure metrics, service checks, heartbeats, kernel-level eBPF security) and the on-call layer is built in, not bolted on.

The OnCall concepts you rely on map directly:

You have in OnCall	AlertKick equivalent
Escalation chains	Escalation policies - sensible three-level defaults, explained here
Schedules and rotations	On-call rosters with rotations and overrides - roster management
Slack / Telegram notifications	Slack, Telegram, WhatsApp, SMS, and email channels
Mobile push via Cloud	Telegram or WhatsApp on your phone - no companion cloud account required
Webhook integrations from your monitoring	The agent and monitors are the alert source - no glue webhooks to maintain
Heartbeat monitoring	Built-in heartbeats for cron jobs and backups

Because the alerts originate inside AlertKick, the AI triage layer sees the event, the host, and the history together. What reaches your phone is the incident, not the noise.

AlertKick is not the right fit if you need a pure routing layer for a large existing Prometheus/Grafana estate you intend to keep. Options 2 or 3 serve you better there. AlertKick earns its keep when the DIY stack itself is the thing you’d rather stop maintaining.

Migration checklist

Before touching anything, inventory what OnCall is actually doing for you - it’s usually less than feared:

1. Export your schedules. Who is on rotation, what the handoff times are, which overrides recur. Most teams have one or two rotations and a handful of ad-hoc overrides.
2. Write down your escalation chains. Level by level: who gets notified, on what channel, after how many minutes. Most chains fit on an index card.
3. List your integrations. Every webhook pointing at OnCall is an alert source that needs a new home. Tag each one: replaced by AlertKick’s agent/monitors, still needed, or dead.
4. Check notification preferences per person. Quiet hours, channel order, phone numbers. Verify this data rather than migrating it blind.
5. Stand up the replacement in parallel. Run both for a week or two. Point a non-critical alert source at the new system first, and send a test page through every escalation level at least once. The only test of a pager that counts is a page that arrives.
6. Only then decommission. Take the OnCall webhook endpoints off the internet the day you stop trusting it, even if the containers keep running internally for reference.

Setting the AlertKick side of that up takes an afternoon: register, install the agent on a test host, recreate your rotation and escalation levels from the index card, and send yourself a test page over Telegram. The free tier covers uptime monitors and heartbeats with no card, so the parallel-running phase costs nothing.