Open-source on-call management is having a real moment in 2026, and the last few weeks made that obvious. IncidentRelay, a new self-hosted platform for on-call scheduling, alert routing, escalations, and incident response, just reached its first stable release (version 1.1) after several beta builds. It landed only a few months after Grafana OnCall, the most widely deployed open-source on-call tool, was archived in March 2026 and left thousands of teams looking for a home. If you run reliability for a living, this is the moment to reopen a question you probably shelved years ago: should your on-call stack be something you buy, or something you own?
This post breaks down what changed, what IncidentRelay and its peers actually do, the true cost of self-hosting versus a managed platform, and a practical framework for making the build versus buy call for on-call in 2026. The short version: the license was never the expensive part, and the decision that matters most is not where the software runs, it is where the alert finally reaches a human.
On-call tooling used to feel settled. You paid PagerDuty or Opsgenie, wired up your monitors, and moved on. That consensus is cracking for a few reasons at once: pricing fatigue with per-seat SaaS, a wave of data sovereignty and self-hosting requirements, and a gap in the open-source market that appeared almost overnight when a popular tool was retired.
For years, Grafana OnCall was the default answer for teams that wanted on-call scheduling and escalation without a SaaS bill. When the project was archived in March 2026, a large base of self-hosted users suddenly had a tool with no future roadmap, no security patches on the horizon, and no clear migration path. That is the kind of event that forces action. Nobody wants their paging system, the thing that is supposed to wake someone up when production is on fire, sitting on abandoned code.
The vacuum pulled in new and revived projects. IncidentRelay arrived as a fresh, MIT-licensed platform built specifically for this role. Others, like GoAlert and a growing set of Grafana OnCall replacements offering one-click migration, moved to catch the stranded users. When an incumbent open-source tool disappears, the ecosystem does not shrink, it fragments and then re-forms, and 2026 is very much the re-forming phase.
It helps to be precise about what these tools are, because the category name confuses people. IncidentRelay is not a monitoring system. It does not watch your metrics or scrape your logs. It sits between your existing monitoring tools and the people responsible for responding to their alerts. That distinction matters when you are scoping a replacement, because it means the tool has to integrate cleanly on both sides: it ingests from your observability stack, and it delivers to your humans.
On the intake side, IncidentRelay integrates with Prometheus Alertmanager, Grafana Alerting, AWS SNS and CloudWatch, Zabbix, Sentry, LibreNMS, RMON, and generic webhooks. When an alert arrives, the platform verifies its source, labels, severity, routing rules, and team ownership, then forwards it to the right on-call responder. From there the alert can be acknowledged, resolved, silenced, or escalated if nobody answers.
It covers the scheduling primitives you expect from mature on-call software: recurring rotations, temporary overrides, reminders, escalation chains, maintenance windows, and alert silences for planned work. Unacknowledged alerts trigger repeated reminders before escalating to the next person, which is the core mechanic that stops a critical page from dying in someone's Do Not Disturb settings. It also ships group-based access controls, multi-team support with a unique intake token per route, documented OpenAPI endpoints, personal API tokens, and even a Terraform provider so you can manage configuration as code.
On operations, it behaves like a proper self-hosted app. You run it against your own database, with SQLite for small single-node setups and PostgreSQL recommended for anything larger. Deployment options include Docker Compose, a Helm chart for Kubernetes, and manual systemd installation, with an RPM repository for RHEL-compatible distributions. It is written primarily in Python and distributed under the permissive MIT license. In other words, it is a serious attempt at a self-hostable PagerDuty alternative, not a weekend hack.
The most common reason teams look at open-source on-call is cost, and the headline numbers are genuinely compelling. But the license fee is the part everyone can see, and it is rarely the part that hurts. To make a good decision you have to price both sides honestly.
Managed on-call platforms usually charge per user, per month, and the responder count grows faster than people expect. It is not just your SRE team. It is every backend engineer who owns a service, the platform team, the on-call managers, and often product engineers who get looped into severity reviews. A mid-sized engineering org can easily land a few hundred paid seats, and premium tiers with advanced routing, analytics, and event orchestration push the per-seat price up sharply. Teams routinely describe the annual figure as a five or six figure vendor tax, and at renewal time that number gets scrutiny from finance in a way that a self-hosted box on a mid-range server simply does not.
Self-hosted open source flips the model. You pay for infrastructure, not headcount. A team of fifty responders can run on a modest virtual server that costs roughly what a couple of SaaS seats would, because the pricing is decoupled from how many people you add. For a large org, or one where on-call responsibility is deliberately spread wide to avoid burning out a small group, that decoupling is the whole argument.
Here is the part the cost-per-seat comparison charts leave out. When you self-host your paging system, you become the on-call for your on-call. If IncidentRelay or GoAlert goes down at 3am, there is no vendor to page, because you are the vendor. That means your paging stack now needs its own high availability, its own monitoring (ideally from a separate blast radius than the systems it watches), its own backups, its own patching cadence, and its own runbook for the day it fails.
None of that is exotic for a team that already runs Postgres and Kubernetes in production. But it is real engineering time, and engineering time is the most expensive line item most orgs have. The honest way to frame the tradeoff: owning the stack means you handle hosting and maintenance, which is a fair trade for teams with the infrastructure muscle to support it, and a bad trade for teams without it. A self-hosted tool that your one overloaded platform engineer cannot keep patched is not cheaper than SaaS, it is a latent incident.
There is a second hidden cost that is easy to miss until it bites: dependency isolation. A paging system has one job, to work when everything else is broken. If you host it inside the same cloud region, the same Kubernetes cluster, or behind the same load balancer as the services it monitors, then the outage that should trigger a page can also take down the thing that sends the page. Teams that self-host well run their on-call stack in a deliberately separate failure domain, sometimes a different cloud provider entirely, so a regional incident does not silence the alarm at the exact moment it matters most. That isolation is achievable, but it is design work and ongoing cost that never shows up in a per-seat comparison, and it is the sort of thing a mature managed vendor has already solved for you.
Instead of arguing open source versus SaaS in the abstract, run your situation through a few concrete questions. The right answer is different for a ten-person startup than for a regulated bank, and pretending otherwise is how teams end up with tools they resent.
Owning your on-call stack tends to win when several of these are true. You have hard data residency or sovereignty requirements that make sending alert metadata to a third party a compliance problem. You already operate the underlying infrastructure (Postgres, Kubernetes, secrets management) competently, so adding one more service is marginal. Your responder count is large enough that per-seat pricing genuinely dominates your budget. You want deep customization or infrastructure-as-code control over routing and escalation, which a Terraform provider and open APIs make possible. And critically, you have the on-call maturity and staffing to treat the paging system itself as a tier-one production service.
If most of those describe you, a tool like IncidentRelay is a legitimate, grown-up choice, not a corner-cut. The MIT license, the Terraform provider, and the multi-team access model show it was built for teams that want real control.
Buying wins when your constraint is people, not money. If your team is small, if reliability engineering is a part-time hat somebody wears, or if you cannot credibly promise that your paging system will have better uptime than the services it protects, a managed platform is the safer bet. You are effectively paying a vendor to be on-call for the thing that keeps you on-call. That is often worth every cent, especially early, when an hour of engineer time is scarcer than a SaaS invoice.
There is also a middle path worth naming. Plenty of teams keep a managed core for the reliability guarantee while pushing more of the actual workflow, the acknowledgements, the coordination, the human back-and-forth, into the place their engineers already live. Which brings us to the part of this decision that almost nobody prices correctly.
Build versus buy debates obsess over the backend: the database, the deployment model, the license. But the backend is not where incidents get resolved. Incidents get resolved by people talking to each other, quickly, with context, usually under stress. The single biggest predictor of a fast resolution is not which alerting engine fired the page, it is how little friction sits between the alert and coordinated human action.
Look at the integration lists for these tools and you will notice something: every one of them, IncidentRelay included, treats Slack as a primary delivery target alongside email, SMS, and push. That is not an accident. For most engineering teams, Slack is already the incident bridge. It is where the war room forms, where the timeline gets written in real time, where someone drops the graph that cracks the case. An alert that lands in Slack, where the responder can acknowledge, pull in the next person, and start the timeline without tab-switching, resolves faster than one that lands in a separate console the responder has to go log into at 3am.
This is exactly the gap a Slack-native on-call tool like Pagerly is built to close. Pagerly runs on-call schedules, rotations, overrides, and escalations directly inside Slack, so the rotation, the page, the acknowledgement, and the coordination all happen in one place rather than scattered across a paging console, a status page, and a chat window. Whether your alerting engine is a self-hosted open-source box you own or a managed platform you buy, the last mile is a human in a channel, and shortening that last mile is where mean time to resolution is actually won. The build versus buy question decides who owns the backend. The Slack-native question decides how fast your team moves when it counts.
The practical implication for anyone re-evaluating their stack in the wake of the Grafana OnCall archival: do not just swap one alerting engine for another and call it a migration. Use the forced move as a chance to fix the last mile too. A cheaper backend that still dumps responders into a clunky console is a lateral move. A backend plus a Slack-native workflow that meets engineers where they already are is an upgrade.
If the IncidentRelay release or the Grafana OnCall sunset has you reconsidering, walk through this before you commit. A paging system is not a place to learn migration lessons the hard way.
The arrival of IncidentRelay 1.1 and the retirement of Grafana OnCall are two sides of the same story: open-source on-call management is alive, competitive, and worth a serious look in 2026. For teams with data sovereignty needs, large responder counts, and the operational muscle to run one more tier-one service, self-hosting is a legitimate way to escape per-seat pricing and own your stack end to end. For teams whose real scarcity is engineering time, a managed platform remains the safer choice, because paying someone to be on-call for your pager is often the best money reliability spends.
But whichever way you go on build versus buy, do not lose sight of the part that actually determines how fast you recover: the last mile, where a stressed human reads an alert and has to act. Keep that mile short. Keep it in the place your team already works. That is the difference between a paging system that merely fires and one that helps you resolve, and it is the reason a Slack-native approach to on-call keeps mattering no matter what runs underneath it.