Alert Routing Without PagerDuty: 2026 Guide to Open Source & Budget-Friendly Alternatives

PagerDuty built the category. For over a decade, it's been the default answer when someone asks "how do we get paged when production breaks?" But defaults get challenged when pricing doesn't match the problem you're actually solving, and in 2026, a lot of small engineering teams are doing that math and not liking the result.

Introduction: Why Teams Are Moving Away From PagerDuty

The core issue isn't that PagerDuty is bad. It's that PagerDuty is priced and built for organizations with incident commanders, dedicated SRE teams, and compliance requirements that justify enterprise tooling. A 6-person startup doesn't need status pages with custom RBAC, AI-powered incident summaries, or analytics dashboards tracking MTTA across forty service tiers. They need to know when the API goes down and who should get a phone call about it.

Pricing is the first trigger. PagerDuty's per-user, per-month model adds up fast once you cross a handful of responders, and the jump from the basic tier to anything with real escalation flexibility often lands you in "talk to sales" territory. For a bootstrapped team or an early-stage startup, that's budget better spent on infrastructure or, frankly, on another engineer.

The second trigger is complexity. PagerDuty has grown into a full incident management platform: postmortem tooling, status pages, AIOps features, workflow automation builders. All of that is genuinely useful at scale. But if your actual requirement is "route this alert to the right person, escalate if they don't respond, and let them snooze it from their phone," you're paying for and navigating a UI built for problems you don't have yet.

Alert routing, at its core, is a narrower, more mechanical problem than most SaaS pricing pages make it look. It's conditional logic: given this alert, determine who's on call, notify them through the right channel, escalate if unacknowledged, and log what happened. You don't need a platform to do that. You need a routing engine, a notification layer, and a schedule.

This guide walks through what alert routing actually requires, then evaluates the realistic alternatives: open source projects you self-host, commercial tools priced for small teams, and DIY approaches using infrastructure you probably already have. By the end, you should be able to map your team's actual needs to a tool (or a small stack of tools) without over-provisioning for problems you don't have.

Understanding Alert Routing Fundamentals

Alert routing is the process of taking a signal (a failed health check, a threshold breach, an error spike) and getting it in front of the right human, through the right channel, within an acceptable time window. It sounds simple until you write out what "right person," "right channel," and "acceptable time window" actually require in practice.

Escalation policies define what happens if the first notified person doesn't respond. This usually means a chain: notify person A, wait N minutes, notify person B if no acknowledgment, then maybe notify the whole team or a manager. Escalation policies are the difference between "we paged someone" and "we paged someone and made sure someone actually saw it."

On-call scheduling determines who's "person A" at any given moment. This gets complicated fast: rotating weekly schedules, overrides for vacations, follow-the-sun rotations across time zones, secondary on-call for backup coverage. A tool that handles alert routing but can't manage schedules forces you to manually update who's first-in-line every week, which doesn't scale past a team of two.

Notification channels are how the alert actually reaches someone: SMS, phone call, push notification, Slack DM, email. Phone calls and SMS matter more than people think, because Slack notifications get missed when someone's asleep or away from their laptop. A routing system that only supports Slack is a routing system that will eventually fail to wake someone up for a 3 AM outage.

Here's where alert routing differs from basic alerting: alerting is "send a notification when X happens." Routing is "determine who should receive the notification, through which channel, with what escalation path, based on schedules and policies that change over time." Monitoring tools like Datadog, Prometheus, and UptimeRobot-style uptime checkers are good at detecting problems. Most of them are mediocre at routing those detections to the right human reliably, which is exactly the gap PagerDuty-style tools were built to fill.

If you're trying to reduce the volume of noise hitting your routing layer in the first place, it's worth reading how to reduce false positive alerts in monitoring systems before you even get to routing. A perfectly engineered routing system still burns people out if it's routing garbage alerts.

Requirements checklist for small teams:

• Escalation policies with configurable timeouts
• Rotating on-call schedules with override support
• Multi-channel notifications (at minimum: push, SMS, and one async channel like Slack)
• Acknowledgment and resolution tracking
• Integration with your existing monitoring stack via webhooks or native plugins
• Basic incident history/audit trail
• Reasonable setup time (days, not weeks)
• Pricing that scales linearly with team size, not punitively

If a solution handles all of the above, it's a legitimate PagerDuty alternative regardless of whether it's open source or commercial, self-hosted or SaaS.

Open Source Alert Routing Solutions

Open source is the obvious first stop for cost-conscious teams, and in 2026 the options are genuinely more mature than they were even two years ago.

Grafana OnCall is the most complete open source option right now. It handles on-call scheduling, escalation chains, and multi-channel notifications (SMS, phone calls via Twilio integration, mobile push through the Grafana IRM app, Slack, Telegram). If you're already running Grafana for dashboards, OnCall integrates natively with Grafana Alerting, which means your existing alert rules can route straight into on-call schedules without extra glue code.

Setup complexity is moderate. If you self-host Grafana already, adding OnCall is mostly a matter of deploying the plugin and configuring integrations. If you're starting from scratch, you're standing up Grafana plus OnCall plus whatever you use for actual monitoring (Prometheus, VictoriaMetrics, etc.), which is a half-day to multi-day project depending on your infra familiarity. Grafana also offers a hosted cloud version of OnCall with a free tier, which removes the self-hosting burden if you don't want to run infrastructure to manage your infrastructure alerts.

The main limitation: OnCall is built around the Grafana ecosystem. It works with other tools via generic webhooks, but the experience is smoothest if your monitoring already lives in Grafana. Teams on Datadog or New Relic can still integrate, but expect more manual webhook configuration.

Alertmanager, part of the Prometheus ecosystem, deserves a specific callout because people often assume it's a full routing solution and it isn't, not on its own. Alertmanager is excellent at grouping, deduplicating, and routing alerts based on labels, silencing noisy alerts, and inhibiting redundant notifications. What it lacks natively: on-call scheduling, escalation with time-based retries to different people, and multi-channel notification delivery like SMS or phone calls. You can bolt these on by pairing Alertmanager with something like Grafana OnCall (which has native Alertmanager integration) or a custom webhook receiver, but Alertmanager by itself is a routing engine, not a complete on-call management system. If your whole stack is Prometheus-based, Alertmanager plus OnCall is a strong combination. Alertmanager alone, for a team that needs phone calls at 2 AM, is not sufficient.

Self-hosted Opsgenie-style alternatives are thinner on the ground than you'd expect. Opsgenie itself (owned by Atlassian) isn't open source, and most "alternatives" in this space are either Grafana OnCall, commercial SaaS tools, or roll-your-own stacks. If you were hoping for a drop-in self-hosted Opsgenie clone, it doesn't really exist as a mature project in 2026. The honest answer is: Grafana OnCall is the closest thing, and beyond that you're building your own with workflow tools.

n8n and Zapier represent a different philosophy: workflow-based routing instead of purpose-built on-call software. n8n, which is open source and self-hostable (or available as a paid cloud service), lets you build a flow that receives a webhook from your monitoring tool, checks conditions (severity, service, time of day), looks up who's on call (from a Google Sheet, Airtable, or a simple database), and sends notifications through Slack, SMS (via Twilio), or email. Zapier does the same thing without self-hosting, at the cost of per-task pricing that can get expensive at alert volume.

The appeal here is flexibility: you're not constrained by what a vendor decided escalation policies should look like. The downside is that you're building and maintaining the on-call scheduling logic yourself, which is the hardest part of this entire problem. Workflow tools are great for routing once you know who's on call. They're not great at being the source of truth for complex rotating schedules, unless you pair them with a dedicated scheduling tool or build that logic yourself.

Emerging tools in 2026 worth watching: smaller open source projects focused specifically on "lightweight PagerDuty replacement" have been popping up on GitHub, often built by teams who hit the exact pricing wall this guide is about. Most are early-stage, meaning you'd be an early adopter dealing with rough edges, missing integrations, and smaller communities for support. Grafana OnCall remains the safest open source bet for teams that want something production-ready today rather than a promising project to bet on.

Commercial Alternatives to PagerDuty (Non-Enterprise Pricing)

If self-hosting isn't appealing, there's a healthy crop of commercial tools built specifically to undercut PagerDuty on price while covering the same core routing functionality.

Incident.io started as an incident management tool and has built out solid alerting and on-call functionality on top of it. It's Slack-native, meaning most of the incident workflow (declaring, updating, resolving) happens inside Slack itself, which lowers the learning curve significantly for teams that already live in Slack. Pricing is usage-based and tends to be more approachable than PagerDuty's at small team sizes, though it can grow if you lean heavily into the full incident management suite rather than just routing.

Squadcast positions itself directly as a PagerDuty alternative and it shows: escalation policies, on-call scheduling, status pages, and SLO tracking are all there, generally at a lower price point per user. Squadcast's free tier is usable for small teams testing the waters, and paid tiers scale more gently than PagerDuty's. The tradeoff is a smaller integration ecosystem; most major monitoring tools are supported, but you'll find fewer long-tail integrations than PagerDuty's marketplace offers.

ilert is a European alternative (GDPR-relevant for teams with EU compliance needs) with notably transparent pricing published directly on their site rather than hidden behind a sales call. It covers alerting, on-call scheduling, status pages, and incident communication. For teams specifically concerned about data residency in the EU, ilert is one of the few options built with that as a first-class concern rather than an afterthought.

PagerTree leans into being the budget option without pretending otherwise. It covers escalation policies, scheduling, and multi-channel notifications at a price point noticeably below PagerDuty and even below some of the other alternatives here. It's a good fit for teams that want the routing fundamentals covered well without paying for incident management extras they won't use. The UI is less polished than Incident.io or Squadcast, but the core functionality is solid.

Splunk On-Call (formerly VictorOps) has gone through pricing and positioning shifts since the Splunk acquisition. It's more accessible than it used to be for mid-size teams, but it's worth checking current pricing directly, since this is a product that's been repositioned a few times and older pricing comparisons floating around the internet are often stale.

Comparison table: features vs. cost for small teams

If you're still weighing whether a dedicated status page matters alongside your alerting setup, this comparison of StatusPage vs custom status pages is a useful companion read, since several of these tools bundle status pages in, and it affects the real total cost comparison.

Building Custom Alert Routing With Existing Tools

Not every team needs a dedicated product at all. If you're small enough, you can build functional alert routing from pieces you probably already pay for.

Slack + native Workflows is the simplest starting point. Slack's built-in Workflow Builder can route incoming webhook payloads to specific channels, tag specific people based on simple conditions, and trigger follow-up reminders if a message isn't reacted to within a time window. It's not a replacement for phone-call escalation, but for teams where "someone sees it in Slack within 10 minutes" is an acceptable bar, it's free (if you already pay for Slack) and requires zero infrastructure.

The limitation is obvious: Slack notifications don't wake anyone up reliably. If your incidents can wait for business hours or you have a culture of actively watching Slack during on-call shifts, this works. If you need someone pulled out of sleep for a payment processing outage, you need SMS or phone escalation, which means pairing Slack with something else.

Webhooks from your existing monitoring stack (Prometheus, Datadog, New Relic, or an uptime monitor like Uptiqr) are the connective tissue for almost every DIY setup. Nearly every monitoring tool supports outbound webhooks on alert trigger, which means you can route that payload anywhere: a Slack workflow, an n8n flow, a Lambda function, or a dedicated routing tool. The key cost consideration here is that webhooks are table stakes. If your current monitoring tool doesn't support them, that's a more fundamental problem than your routing layer.

Serverless functions (AWS Lambda, Google Cloud Functions) let you build genuinely custom routing logic: receive the webhook, check a database or config file for who's on call, send an SMS via Twilio's API, wait and check for acknowledgment, escalate to the next person if needed. This is the most flexible option and also the most maintenance-heavy. You're now responsible for the reliability of your alerting pipeline's alerting pipeline, which is a genuinely funny problem to have if your Lambda function silently breaks and nobody gets paged about the thing that's supposed to page people.

Cost analysis: DIY vs. pre-built. A serverless routing setup can cost nearly nothing in infrastructure (a few dollars a month in Lambda invocations and Twilio SMS fees for a small team), but it costs engineering time to build and, more importantly, to maintain as requirements change (new team members, new escalation rules, new integrations). Pre-built tools cost real money monthly but remove that maintenance burden entirely. For a team of 2-3 engineers, the calculus often favors DIY, because engineering time is abundant relative to budget. For a team of 10+ where engineering time is the scarcer resource, a $20-50/user/month tool is usually cheaper in the long run than the hours spent babysitting a homegrown routing pipeline.

If your team is a team of one, the calculus shifts even further: see incident response for solo founders for how routing logic simplifies (or in some ways gets harder) when there's no one to escalate to.

Implementation Checklist: Choosing Your Alert Routing Solution

Before picking a tool, run through this:

Team size and incident frequency. A 3-person team paging itself twice a month has fundamentally different needs than a 15-person team handling daily alerts across multiple services. Smaller, infrequent incident volume favors simpler (even DIY) tools. Higher frequency justifies investing in a more robust commercial product, because the cost of friction multiplies with usage.

Integration requirements. List every monitoring tool, uptime checker, and error tracker you currently use, and confirm native or webhook-based integration before committing. A tool that's cheaper but requires you to build custom glue code for your specific monitoring stack may cost more in engineering hours than the savings justify.

Scalability and growth planning. Will you double headcount in a year? Check whether pricing scales linearly or whether there are cliff-edge tier jumps (common in PagerDuty's own pricing, ironically, which is part of why people leave it in the first place).

Setup time and maintenance burden. Self-hosted open source tools (Grafana OnCall, Alertmanager-based stacks) require ongoing infrastructure maintenance: updates, uptime of the routing tool itself, backups. SaaS options remove this but introduce vendor dependency. Be honest about whether your team has the appetite to run another piece of infrastructure.

Security and compliance. If you handle any regulated data, check SOC 2 status, data residency (relevant if you're EU-based, which is where ilert's positioning matters), and audit log retention. Smaller vendors sometimes lag on compliance certifications that larger teams need for vendor approval processes.

Total cost of ownership. Don't just compare sticker price. Factor in: engineering hours to set up and maintain, cost of SMS/phone minutes (some tools bundle this, others charge per-use), and the cost of switching later if you outgrow the tool. This is the same mental model worth applying across your whole monitoring stack; see monitoring costs for bootstrapped startups for a broader breakdown of where monitoring budgets actually go.

FAQ: Common Questions About Alert Routing Without PagerDuty

What's the cheapest alert routing solution for a 5-person team? For pure cost, a self-hosted Grafana OnCall instance plus Twilio for SMS will run close to infrastructure cost alone, often under $20/month excluding engineering time. If you want zero infrastructure management, PagerTree or Squadcast's lower tiers are the cheapest commercial options that still cover escalation and scheduling properly.

Can we use Slack alone for alert routing and on-call management? For non-critical alerts or teams with an always-on Slack culture, yes, functionally. For anything where a missed notification has real cost (customer-facing downtime, revenue impact), no. Slack doesn't reliably wake people up, and it has no native concept of on-call rotation or phone escalation. Pair it with something else for anything that matters at 3 AM.

How do open source solutions compare to SaaS for reliability? Reliability depends entirely on your own infrastructure if self-hosted. Grafana OnCall is solid software, but if your Kubernetes cluster goes down and OnCall goes down with it, you've lost your alerting layer exactly when you need it. This is the classic "who pages the pager" problem. Many teams mitigate this by using OnCall's hosted cloud offering instead of self-hosting, or by running the routing layer on separate infrastructure from what it's monitoring.

What happens if our alert routing tool goes down? This is worth testing deliberately, not assuming. For SaaS tools, check their own status page and historical uptime. For self-hosted tools, this is the strongest argument for keeping your routing infrastructure separate from the infrastructure it's alerting on, ideally in a different region or even a different cloud provider entirely.

How do we migrate from PagerDuty without losing incident history? Most alternatives support CSV or API-based import of schedules and escalation policies, but historical incident data (timestamps, resolution notes, postmortems) is harder to migrate cleanly since data models differ between tools. Export everything from PagerDuty before canceling (most tools allow data export for a limited window post-cancellation), and consider keeping a static archive even if it's not imported into the new tool. If incident history and documentation matter to your compliance or retro process, it's worth reading incident timeline documentation for small teams before you finalize a migration, since the new tool's documentation capabilities might shape which one you pick.

One last practical note: whatever you land on, the health of your alert routing system is only as good as the alerts feeding into it. A perfect escalation policy routing garbage, noisy, or duplicate alerts just burns out whoever's on call faster. If you haven't audited your alert sources recently, that's worth doing in parallel with any routing migration, not after it. Pairing a lean routing setup with solid multi-channel alerting and realistic on-call practices (see on-call fatigue prevention) matters more than which specific vendor logo is on the invoice.

Related Articles

• StatusPage vs Custom Status Pages: Which Solution Is Right for Your Team in 2026?
• Incident Timeline Documentation: A Complete Guide for Small Teams in 2026
• Monitoring Costs for Bootstrapped Startups: A 2026 Guide to Affordable Uptime Solutions