Grafana OnCall OSS Alternatives After Archival

In one sentence

Grafana OnCall OSS is archived, a self-hosted instance still runs, and the part that broke is delivery to a phone — so the decision is which notification path replaces the one that ended, and whether that repair is worth doing inside archived software.

What changed, and when

Grafana Labs placed OnCall (OSS) into maintenance mode on 2025-03-11 with a year's notice. The announcement's timeline named 2026-03-24 as the date the project would be archived, and the same date the Cloud Connection would be disabled.

Grafana's documentation carries a caution that the OnCall OSS notifications which rely on Grafana Cloud services are no longer available after that date. The grafana/oncall repository moves to read-only, and Grafana directs OSS users to Grafana Cloud IRM.

Two dates matter when you plan. 2025-03-11 is when feature work stopped. 2026-03-24 is when parts of a running install stopped working.

What still works in your existing install

Grafana's documentation is direct about this: the software continues to function in your environment, and your on-call schedules, integrations and workflows remain operational. The maintenance-mode post adds that users can continue to use any current OnCall (OSS) deployment indefinitely.

So there is no forced shutdown date on your instance. Rotations are still computed, the interface still loads, alert rules still route. What you lost is not the scheduler. It is the last hop.

What stopped working, and why

Push, SMS and voice were never local features of the OSS install. They were delivered through Grafana's Cloud Connection, which is why they ended when the connection did.

After 2026-03-24, Grafana ended Cloud Connection support. Mobile app push notifications are no longer supported for OSS users, and SMS and phone call notifications that relied on the Cloud Connection are no longer supported either. Grafana's guidance is that OSS users will need to seek alternative notification services for phone, SMS and mobile push, and the maintenance-mode post states that the APIs, Cloud Connection and other services stop working with OnCall (OSS) after that date.

Build a requirements inventory before you shortlist

Comparing products before you have written down your own requirements means choosing against someone else's criteria. Write one page first. The rows below usually settle it.

Then mark each row as a binding constraint or a preference. Sort the page that way before you look at any product, and carry the binding rows into every conversation with a vendor.

Stay self-hosted, or move to managed

The second row is the easiest one to skip. An on-call system is infrastructure that must work when other infrastructure does not, and it needs a failure path of its own — a heartbeat, an independent check, or an agreed fallback contact list that does not live inside the tool being replaced.

Four categories of option

These are categories, not a ranking. Which one fits is decided by your inventory.

(a) Keep OnCall OSS and replace only the notification channels. Grafana documents both halves. For phone and SMS, OnCall OSS already supports configuring your own Twilio account credentials; the maintenance-mode post also mentions Exotel, Zvonok, or webhooks. For push, you can configure a third-party service such as Pushover, Gotify or ntfy through outgoing webhooks in personal notification rules. Grafana presents these as workarounds for the broken channels, not as a migration path — you keep archived software and you now own the provider relationships and the delivery testing. Fits when schedules and escalation logic already match how the team works and someone has capacity to operate it.

(b) Move to the vendor's managed successor. Grafana recommends Grafana Cloud IRM as a fully managed alternative for teams that want to retain full mobile push notifications and built-in SMS and voice call support, and notes that the Grafana Cloud free tier includes three users. Fits when the concepts map closely to what you already run and hosted delivery is acceptable to your data-location row.

(c) Move to another managed on-call product. Fits when the inventory turns up requirements the successor does not meet, or when concentrating monitoring and paging with one vendor is itself the concern. Evaluate against your own inventory rather than a feature list: does it deliver the channels you actually use out of hours, express your rotation shape, run your escalation depth, and record what your auditors ask for. Send a real test page during a trial before you migrate a single schedule.

(d) A focused monitoring-and-alert-delivery product. If your inventory lists uptime checks, heartbeats for scheduled jobs, a webhook receiver, one or two rotations and a short escalation path — and says nothing about incident command, postmortems or stakeholder communication — then a full incident-management suite is more product than the requirement. Detection and notification is a smaller problem than incident management, and solving the smaller one well is a legitimate outcome.

Migration checklist

1. Freeze configuration changes in the old system, and say so in writing.
2. Export schedules, rotations, overrides, escalation policies, integrations, routing rules, personal notification rules and contact details. Keep the export; it is also your rollback reference.
3. Rebuild in the target for one team first, not all of them.
4. Point one low-severity alert source at the new path while the old one keeps running.
5. Run both in parallel for at least one full rotation, covering a weekend and a handover.
6. Move the remaining sources severity by severity, lowest first.
7. Update runbooks and the on-call policy with the new acknowledge path and the new escalation timings.
8. Decommission the old route only after a clean parallel period, and disable before you delete.

Testing and cutover

A migration is finished when a person has been woken by the new system and knew what to do, not when the configuration validates.

Test the complete route: real alert source, into the new system, through escalation step one, to a locked phone at night with do-not-disturb as the responder normally has it. Then leave it unacknowledged and confirm the secondary is reached at the timing you configured. Then break it on purpose — primary's phone off, network switched — and see what the escalation does.

Record who tested, on which device and network, and when. That record is what tells you whether the coverage you believe in is coverage you have observed.

A worked example (invented, for shape only)

A platform team of nine runs one primary rotation with a weekly handover, a secondary, and six alert sources. Out of hours, pages arrive by push and voice. Their inventory shows no config-as-code, two escalation steps with no repeat, an EU-only data-location requirement, and an audit requirement to show who was paged and when for the previous twelve months.

Two rows are binding: EU-only hosting, and the twelve-month paging record. Push and voice are the broken part. Their shortlist reduces to (a) if they keep operating the install, or (b) or (c) filtered by hosting region and audit retention. They run a parallel week, move sources lowest severity first, and keep the old routes disabled for one rotation after cutover.

What to do next

• Send a test page through your current OnCall OSS install to a locked phone. Note which channels arrive.
• Write the one-page requirements inventory. Mark the one or two rows that are binding.
• Decide which of the four categories your binding rows allow, and rule out the rest in writing.
• Name a rollback trigger, a decision-maker and a mechanism before you touch any routing.
• Book the parallel run into a rotation that includes a weekend, and tell the team it is happening.