DEV Community: Yathartha Shekhar

Runbooks the On-Call Engineer Will Actually Open at 3am

Yathartha Shekhar — Fri, 09 Oct 2026 18:22:50 +0000

Key takeaways

Most runbooks are written by someone calm, at a desk, with full context, for a reader who is none of those things during an actual incident. That mismatch, not a lack of documentation effort, is why so many runbooks exist and don't get opened.
A runbook that gets used at 3am is scannable in seconds, structured as decisions and commands rather than prose explanation, and current enough that the on-call engineer trusts it over their own memory.
Staleness is the silent killer: a runbook that's wrong once teaches the team to stop trusting all of them, which is worse than having no runbook at all.

Why on-call runbooks don't get opened

A runbook is usually written right after an incident, or during a calm sprint dedicated to documentation, by someone who understands the system well and has time to explain it properly. It gets read, if it gets read at all, by someone at 3am, cognitively impaired by being woken up, under time pressure, trying to stop something from getting worse. Those are two completely different reading conditions, and a document written for the first one is very often unusable in the second. Not because it's wrong, but because it's shaped for the wrong reader.

The tell is a runbook that starts with background: why the system works the way it does, historical context, the reasoning behind a design decision. All of that is genuinely valuable at some point, just not at 3am, when the reader needs the fourth paragraph's worth of information in the time it takes to skim a heading.

None of this means runbooks aren't worth writing. Google's SRE workbook describes the norm in its on-call chapter: whenever an alert is created, a matching playbook entry usually is too, because good ones reduce stress, time to repair, and the risk of human error. The problem is the shape of the document, not the habit of writing one.

What makes an on-call runbook actually get opened

Scannable in seconds, not read start to finish: headings that are actions or symptoms ("Service returning 503s", not "Background on the service architecture"), so the on-call engineer can jump to the relevant section without reading the whole document to find it. A runbook that requires reading top to bottom to find the relevant part won't get read that way under pressure. It'll get abandoned in favor of guessing.

Commands, not descriptions of commands: "Run kubectl rollout restart deployment/api -n prod" beats "restart the API deployment in the production namespace." A tired person copy-pastes a command far more reliably than they correctly translate a description into one, and a typo in a hand-typed command during an incident is its own risk.

Decision structure, not narrative prose: "If X, do Y. If Y doesn't work, do Z." reads faster under pressure than a paragraph explaining the same logic. The runbook's job in the moment is to be a lookup table, not an essay.

One clear owner and one clear scope per runbook: a runbook trying to cover an entire service's worth of possible failures becomes a wall of text nobody can navigate quickly. Narrow runbooks, one per failure mode, linked from wherever that failure mode's alert fires, work better than a single sprawling document covering everything. If an alert fires often enough to need a runbook but nobody can say what action it calls for, that's an alert problem, not a documentation problem; see why alert fatigue survives every tooling migration.

The runbook staleness problem

A runbook that's wrong is worse than no runbook. The first time someone follows stale instructions and it makes things worse, or just wastes ten critical minutes, they stop trusting runbooks generally, not just that one. That erosion of trust is expensive to rebuild and cheap to avoid, mostly by keeping runbooks narrow enough that updating them isn't a big lift, and by treating a runbook that turned out to be wrong during a real incident as something the postmortem should explicitly fix, not something that quietly stays wrong until the next person hits it. The same SRE workbook chapter puts it plainly: playbook details go out of date as fast as the production environment changes.

A useful practice: whenever a runbook gets followed during a real incident, note in the postmortem whether it was accurate and current. If it wasn't, fixing it is a concrete action item, the same way fixing a bad alert rule would be. Keeping runbooks in the same repository as the alert rules, reviewed in the same pull request, helps for the same reason it helps with escalation policies as code: a change to one prompts a look at the other.

Where runbooks should actually live

A runbook that's hard to find in the moment is functionally the same as a runbook that doesn't exist. Linked directly from the alert that would trigger needing it, or from the incident record once one's declared, beats a wiki search that assumes the on-call engineer remembers the right search term while half-awake. The goal is zero navigation between "I got paged" and "I'm looking at the relevant runbook." Every extra click is a chance to give up and start improvising instead.

If you run Prometheus, this is built in: alerting rules have an annotations field meant for exactly this kind of longer information, and the Prometheus docs name runbook links as a use for it. The convention is a runbook_url annotation on each alert, which Alertmanager passes along with the alert to whatever pages you. The kube-prometheus runbooks are a good public example: every alert in that project points at its own short page, like this one for TargetDown.

A quick runbook audit

Pick a runbook and time how long it takes a fresh pair of eyes to find the first actionable command in it, starting from the top. If it's more than a few seconds, it's probably too front-loaded with context that belongs later in the document, or in a separate reference doc entirely, not in the thing someone's trying to use under pressure.

An on-call runbook template

A shape that keeps the actionable part on top:

Symptom: the alert name and what the person paging will actually see.
Impact: who or what is affected, in one line, so the reader can judge urgency.
First command: the one thing to run first, copy-pasteable.
If this, then that: two to five decision steps, each with its command.
Escalate when: the point at which to stop and page someone else, and who.
Background: architecture notes and history, at the bottom, for later.
Last verified: the date and incident when someone last followed it and it worked.

FAQ

What should an on-call runbook include? The symptom, the impact, the first command to run, a short decision tree, when to escalate, and the date it was last verified. Background belongs at the bottom, not the top.

Should runbooks be written by the person who built the system? They're the best starting source, but the person testing whether it's usable should ideally be someone less familiar with the system. Familiarity is exactly what makes a writer blind to steps that feel obvious to them and aren't to anyone else.

How often should runbooks be reviewed? Whenever the underlying system changes meaningfully, and whenever one gets used during a real incident, which is the best signal for whether it's actually still accurate. A calendar-based review cadence catches less than usage-triggered review does.

Is a runbook different from a postmortem? Yes. A postmortem explains what happened after the fact; a runbook tells someone what to do while something is still happening. Conflating the two formats, by adding runbook-style fix steps to a postmortem or narrative explanation to a runbook, weakens both.

Is a runbook different from a handoff note? Yes. A runbook covers a failure mode in general; a handoff note covers one specific incident's state at a shift change. Both matter at 3am. For the handoff side, see who owns the pager when the team is spread across time zones.

One disclosure: we build FluidifyAI Regen, and this is part of why it keeps every alert, annotations like runbook_url included, attached to the incident that alert opened, instead of assuming the on-call engineer remembers where to look.

Who Owns the Pager When the Team Is Spread Across Time Zones

Yathartha Shekhar — Wed, 07 Oct 2026 05:16:26 +0000

Cross-posted from the Fluidify blog.

Key takeaways

Follow-the-sun on-call fixes the fatigue problem of one timezone carrying every 3 a.m. page, and creates a different one: ownership that spreads across every handoff instead of sitting with one accountable person.
The usual failure isn't a missed page. It's a page someone acknowledges without the context to act on it, because the previous shift's understanding of the incident didn't transfer.
A real handoff needs a written artifact, not a verbal aside in a chat channel, plus a named owner for each open incident and an explicit answer to "who owns this until the next handoff," not an assumption that whoever's awake will figure it out. That includes a clear rule for pages that fire right at the shift change.

The trade-off of follow-the-sun on-call

A single-timezone on-call rotation has an obvious problem: the same few people absorb every overnight page, indefinitely. Spreading the rotation across time zones, so someone is always in their normal working hours, fixes that. Google's SRE book makes the same case: night shifts are bad for people's health, and a multi-site follow-the-sun rotation lets a team avoid them entirely.

It also introduces a problem that gets discussed far less: an incident that spans a shift boundary now has no single person who owned it from start to finish. Ownership becomes a relay, and relays drop batons.

This isn't an argument against follow-the-sun rotations. The fatigue problem they solve is real (we wrote about why it outlasts every tooling change in why alert fatigue survives every tooling migration). The point is that the ownership problem needs its own explicit fix. Most teams get the scheduling mechanics right, meaning which region covers which hours, without solving it at all.

Where follow-the-sun ownership breaks down

Context loss at handoff: the engineer going off shift knows things that don't transfer by themselves: what's been tried, what's been ruled out, what looked promising but isn't confirmed. If that lives only in their head, or scattered across a chat thread the next person has to reconstruct, understanding is lost at every handoff, and a multi-day incident has many handoffs. Why handover loses context even on single-timezone teams is its own topic, which we cover in a separate piece on on-call handover.

Escalation policies written for one timezone: a policy that escalates to "the engineering manager" after 15 minutes assumes that person is reachable at any hour. Follow-the-sun is supposed to guarantee someone is, but the policy often wasn't rewritten to match who is actually awake and accountable at each point in the cycle. It still names one person by title, not "whoever owns this shift block."

Unclear ownership during the handoff window: the ten or twenty minutes around a shift change are the riskiest part of the day. Is the outgoing engineer still responsible for a page that fires at the boundary, or does the incoming one own it immediately? Without an explicit answer, both sides can reasonably assume the other has it, which is how a page ends up acknowledged late by neither.

Nobody owns "did this actually get fixed": with a single on-call person, they own an incident until it's resolved, by default. Across shifts, "resolved" can quietly turn into "no longer paging," which isn't the same thing. Nobody notices until the issue comes back on a shift that has no memory of the first time.

What real ownership requires

A named owner per incident, independent of whose shift it is: not "whoever's on call right now" but a specific person, usually whoever first triaged it or the incident commander assigned at declaration. They're accountable for the outcome across however many handoffs it takes, even if they're asleep for some of them and pick it back up on their next shift.

A written handoff artifact, every time, not just for the complicated cases: a short, structured note (what happened, what's been tried, what's still open, what to watch for) written by the outgoing person and read by the incoming one before they take the pager. The easy cases don't need it. The problem is you don't know which case you're in until the handoff has already gone badly. Google's SRE workbook describes the same habit in its on-call chapter: read the previous shift's handoff when you start, send one when you finish.

Escalation policies that name a role and a rotation, not a person, and get regenerated as the rotation changes: if "engineering manager" always resolves to the same person regardless of timezone, that's a single-timezone policy with a follow-the-sun label on it. Make each escalation step point at a rotation, and regenerate the policy when the rotation changes. If those policies only live in a vendor UI with no review before a change ships, that's a related and worse problem; see escalation policies as code for the fix.

An explicit boundary rule for pages that fire at the shift change: pick one and write it down. For example: the outgoing person owns anything that fired before the boundary, the incoming person owns everything after, communicated clearly enough that neither side has to guess. Any consistent rule beats an implicit one.

A handoff note template

A handoff note doesn't need to be long. These five lines cover most shifts:

Open incidents: each one with its current owner and status.
What's been tried: including what was ruled out, so the next person doesn't repeat it.
What's still unknown: the open questions, stated plainly.
What to watch: alerts or dashboards that are likely to fire, and what they'd mean.
Changes in flight: deploys, migrations, or config changes that could explain new pages.

Keep it in one place the incoming person will definitely read, such as the incident channel or the incident record, not a DM.

FAQ

What is follow-the-sun on-call? A rotation where on-call duty passes between teams in different time zones over the day, so each person is on call during their own working hours instead of overnight.

Does follow-the-sun make sense for a small team? Usually not below a certain size. You need enough people in each timezone to actually build a rotation there, not just one person covering "their" hours alone, which just relocates the fatigue problem rather than distributing it. Google's SRE book suggests a minimum of six engineers per site for a two-site team.

How long should a handoff note take to write? A few minutes for a quiet shift, longer for an active incident. If it regularly takes much longer, the incident wasn't documented well enough during the shift. The handoff note is the symptom, not the real gap.

Who should write the handoff note, outgoing or incoming? Outgoing, while the context is still fresh. The incoming person's job is to read it and ask questions before taking the pager, not to reconstruct it from scratch.

What tools support follow-the-sun scheduling? Most on-call schedulers support per-schedule timezones and handoffs at set hours. For a comparison of self-hosted options and how each handles timezones, see 10 best self-hosted on-call scheduling tools.

One disclosure: we build FluidifyAI Regen, and this gap is why it has AI-generated handoff digests. They draft the "what happened, what's open, what to watch" note from the incident timeline, so a note exists even on the shifts where nobody had time to write one.

10 Best Self-Hosted On-Call Scheduling Tools

Yathartha Shekhar — Mon, 05 Oct 2026 04:16:40 +0000

Cross-posted from the Fluidify blog. Disclosure: I build FluidifyAI Regen, one of the tools below.

If you're looking for a commercial, proprietary on-call tool you can run on your own infrastructure, the answer is that almost none exist. PagerDuty, Opsgenie, incident.io, xMatters, and most of the category are SaaS-only, no on-premise license at any price. The tools that do run on your own infrastructure are, with rare exception, open source, so "self-hosted" and "open-source" end up covering nearly the same ground here.

So this list only asks one question: how good is each tool at the scheduling job (rotation types, overrides, calendar sync, timezones), and what does it take to run and back up yourself. For the full feature picture across the same tools, see the open-source on-call tools comparison.

Scheduling comparison at a glance

Tool	License	Rotations	Overrides / leave	Calendar sync (iCal)	Self-host footprint	Status (2026)
FluidifyAI Regen	AGPLv3	Layered, primary/secondary, multi-timezone	Overrides, leave, auto public holidays	In-app calendar only	Postgres + Redis, optional HA	Active
GoAlert	Apache-2.0	Hourly/daily/weekly rotations	Overrides, temporary schedules	Yes, subscription feeds	Single Go binary + Postgres	Active
LinkedIn Oncall + Iris	BSD-2-Clause	Rotations, follow-the-sun	Overrides, swaps	Yes, per user and team	Two services + MySQL	Low activity
Grafana OnCall	AGPLv3	Layered rotations	Overrides	Yes, import and export	Several services	Archived March 2026
Keep	MIT core	None, delegates to an on-call tool	None	No	Containers	Active
Zabbix	AGPLv3	None	Maintenance windows only	No	Full monitoring stack	Active
Icinga 2	GPLv2	None	Time periods only	No	Full monitoring stack	Active
Alerta	Apache-2.0	None	None	No	API + database	Low activity
Cabot	MIT	None	None	No	Django app	Dormant
Alertmanager + Karma	Apache-2.0	None	Silences only	No	Two small binaries	Active

What actually differs on the scheduling side

Rotation types: weekly handoff is table stakes. Layered rotations (a primary layer plus a secondary layer, each rotating independently), follow-the-sun across timezones, and custom rotation lengths separate a full scheduling engine from a basic one.

Override handling: swapping a single shift without editing the underlying rotation, and treating holidays and planned leave as first-class exceptions rather than manual one-off edits.

Calendar sync: whether the schedule publishes an iCal feed that Google Calendar, Outlook, or Apple Calendar can subscribe to.

Timezone handling: a follow-the-sun rotation needs each person to see their own shift in their own local time, not everyone reading the same UTC-anchored schedule.

Backup and data ownership: self-hosting means you own the backup story: what database the schedule lives in, and what disaster recovery looks like if it's lost.

Scheduling depth, tool by tool

1. FluidifyAI Regen (AGPLv3): layer-based schedules with primary/secondary layers, overrides, and leave as first-class concepts (mark someone unavailable and the rotation skips them), public holidays pulled in automatically for several countries, and per-schedule timezones with each person seeing shifts in their own local time. Runs on Postgres and Redis, with documented PostgreSQL HA (Patroni) and Redis Sentinel support for more than one node. Imports schedules from Grafana OnCall, PagerDuty, or Opsgenie in one step. Also does escalation and incident coordination. The gap: shifts show in Regen's own calendar view, but as of v1.0 there's no iCal feed for Google Calendar or Outlook.

2. GoAlert (Apache-2.0): built by Target. Hourly, daily, and weekly rotations, overrides that add, remove, or replace someone on a shift, temporary schedules for one-off coverage, and per-user iCal subscriptions. A single Go binary plus Postgres, so one database to snapshot. Scheduling and escalation only, no incident coordination layer.

3. LinkedIn Oncall (BSD-2-Clause, paired with Iris for escalation): a dedicated scheduling calendar with follow-the-sun support, override and swap events, and iCal feeds per user and team. Proven at scale at LinkedIn. Two services to run and back up, on MySQL, and the last Oncall commit was August 2025.

4. Grafana OnCall (AGPLv3, archived March 2026): had layered rotations, overrides, and iCal import and export. Still runs if deployed, but the repo is archived, so no future fixes for a new deployment. Regen can import its schedules, except ones defined as an external iCal URL.

5. Keep (MIT core, separately licensed ee/): alert correlation and workflows, not a scheduler. No rotation engine; it hands alerts to an on-call tool that owns the schedule.

6. Zabbix (AGPLv3 since 7.0): escalation steps and maintenance windows, but no rotation concept. Who gets notified is a static user-group setting.

7. Icinga 2 (GPLv2): notification rules with time periods, but no automatic handoff. Rotations usually mean a script rewriting config.

8. Alerta (Apache-2.0): alert deduplication and routing API, no scheduling at all.

9. Cabot (MIT): lightweight checks with an on-call hook, no schedule engine, no commits since 2023.

10. Prometheus Alertmanager + Karma (Apache-2.0): routing trees and silences, with Karma as the triage UI. Routes by label, not by who's on shift.

For 5 through 10 you'd be building rotation logic yourself on top, usually a cron job or external scheduler feeding config in.

Self-hosting operational checklist

Before picking any of these: what's the backup schedule for the underlying database, what's the recovery time if it's lost, does the tool support more than one instance for availability, and who owns the upgrade process. Budget for this regardless of which one you pick. If you want rotation definitions in version control too, see escalation policies as code.

FAQ

Is there really no commercial self-hosted on-call scheduling tool? Not one we found with genuine on-premise deployment as a standard offering. A few vendors do bespoke on-prem for large enterprise contracts, but that's a custom deal, not a product on a pricing page.

Which of these has the deepest scheduling engine? FluidifyAI Regen and GoAlert: Regen for breadth of rotation types, leave, and timezone handling, GoAlert for a clean, focused implementation in a smaller footprint with iCal built in.

Which ones sync shifts to Google Calendar or Outlook? GoAlert and LinkedIn Oncall publish iCal feeds. Grafana OnCall did, but it's archived. Regen doesn't publish an iCal feed as of v1.0.

Should I pick based on scheduling depth alone? Only if scheduling is your whole need. If you also want escalation and incident coordination in the same tool, see the broader open-source on-call tools comparison.

Choosing between them

If scheduling depth and full incident coordination both matter, FluidifyAI Regen covers the most ground in one self-hosted tool; the installation guide gets a single node running. If you want the smallest footprint and iCal sync out of the box, and are fine with escalation and coordination logic elsewhere, GoAlert's rotation and override handling is solid on its own.

The Cost Structure of Per-Seat Incident Tooling

Yathartha Shekhar — Thu, 01 Oct 2026 03:51:30 +0000

Cross-posted from the Fluidify blog.

Per-seat pricing in on-call and incident tools tracks headcount, not infrastructure cost or usage. The marginal cost of one more responder on a schedule is close to zero for the vendor, the price increase isn't a cost passthrough.

Why per-seat pricing exists

Look at what actually scales with an added seat: a row in a database, a few more notifications a month. None of that costs meaningfully more per user at real scale. Per-seat pricing tracks something else: how many people are at the company buying the software, a proxy for budget, not for load on the vendor's systems.

What's specific to incident tooling is how directly the "seat" maps to something operationally meaningful: whether a real person, at 3 a.m., is reachable to fix a real problem. Charging for that access changes the buyer's incentive around it in a way that charging per seat for a design tool doesn't.

What it distorts

Rationing rotation membership: If adding someone to the rotation costs a license, who's on call stops being purely operational and becomes partly financial. A bad axis to make a staffing decision on.

Seat-count negotiation replacing policy design: Procurement conversations center on the per-seat price instead of whether the escalation policy and schedule design are actually right for the team.

Shadow responders: A senior engineer gets paged through someone else's account, or an unofficial channel exists for escalations that never touch the licensed tool. A symptom of pricing fighting the operational need.

The gap grows with the thing you're trying to do, not shrink: As a team scales, the case for a bigger rotation gets stronger exactly as the bill makes it more expensive.

What actually scales with team size, and what doesn't

Alert volume scales with the number of services, not headcount. Incident count scales with system complexity. None of what a vendor's infrastructure actually handles scales in lockstep with rotation headcount. What does scale with headcount is ability to pay, a legitimate business reason to price this way, a separate question from whether it's the right way to price this specific job.

Alternative models

Flat-rate regardless of team size, usage-based on incident volume, or free/self-hosted with the cost shifted to infrastructure and engineering time. Each has tradeoffs. None are free of distortion, they just distort a different variable than headcount.

FAQ

Is per-seat pricing inherently unfair? Not inherently. The question is whether it fits the specific job, and for a tool whose whole purpose is keeping the right people reachable, charging more for having more people reachable is a strange incentive.

Does a bigger rotation actually cost the vendor more? Marginally, but not proportionally to what per-seat pricing typically charges.

What should a buyer evaluate instead of the per-seat price? Whether the pricing model changes how you'd design the rotation if the tool were free.

This is a big part of why we built FluidifyAI Regen without per-seat pricing on the self-hosted tier, the goal was removing this specific distortion, not just being cheaper.

Migrating Off Opsgenie Before Sunset: A Regen Walkthrough

Yathartha Shekhar — Thu, 24 Sep 2026 06:33:26 +0000

Cross-posted from the Fluidify blog. Disclosure: I work on FluidifyAI Regen.

Opsgenie stopped selling new licenses on June 4, 2025, and Atlassian shuts it down completely on April 5, 2027. Data left on the platform after that date is deleted. If you're still on it, here's a concrete migration path, what transfers automatically, and what doesn't.

The dates that matter

Opsgenie's end-of-sale was June 4, 2025: no new purchases, no new trials. Existing customers keep running until the full shutdown on April 5, 2027, when the platform becomes inaccessible and unmigrated data is permanently deleted.

Independent estimates put a typical Opsgenie migration at six to sixteen weeks depending on integration count and how customized your escalation setup is. That still leaves time if you're reading this in 2026, but "still leaves time" is exactly the situation where migrations quietly slip for another two quarters.

Two paths off Opsgenie

Atlassian's own answer is Jira Service Management: alerting and on-call features move into JSM's Premium and Enterprise tiers, with an automated migration tool and a 120-day window of parallel access to Opsgenie. If your team is already deep in the Jira ecosystem, that's the path of least resistance, read Atlassian's own migration documentation for the specifics.

The other path is moving to a dedicated on-call and incident tool instead of folding into JSM, either because you don't want on-call tied to a ticketing suite, want off per-seat pricing, or want a self-hosted option Atlassian doesn't offer. That's the path this covers, using Regen as the destination.

Step-by-step: migrating to Regen

1. Stand up Regen alongside Opsgenie, don't cut over yet: Self-hosted (free, AGPLv3) or managed cloud, run it in parallel with Opsgenie for the whole migration.

2. Connect your Opsgenie account for migration: Regen's migration path reads your existing config through Opsgenie's API using a read-only integration key. Nothing changes on the Opsgenie side.

3. Review what gets pulled in: Schedules, rotations, escalation policies, and existing integrations. Review each against what's actually live, migrations are the natural point to prune years of drift.

4. Rebuild anything that doesn't map cleanly: Custom Opsgenie routing rules and any tightly-coupled scripts calling its API directly need rebuilding against Regen's equivalent. Budget real time here, it's usually the long pole, not the schedule import.

5. Point a subset of alert sources at Regen, in parallel: Redirect a low-risk source first (staging, a non-critical service), confirm the full path: fires, routes, escalates, notifies correctly.

6. Run both systems in parallel for real incidents: For at least one full on-call rotation, let Regen receive alerts alongside Opsgenie without decommissioning it. This is where subtle escalation-policy differences surface.

7. Cut over integrations fully, one at a time: Once a full rotation runs clean, redirect each remaining integration. Keep Opsgenie read-accessible for historical data.

8. Decommission Opsgenie on your own schedule, ahead of April 5, 2027: Export anything you need for historical record first.

What doesn't migrate automatically

Historical incident and alert data. Export it from Opsgenie separately if you need it for compliance or reporting.
Opsgenie-specific automations referencing Opsgenie object IDs directly, rewrite against Regen's API.
Custom integrations built against Opsgenie's exact webhook payload shape. Most monitoring tools support a generic webhook format both platforms consume.

A realistic timeline

For a mid-sized team: weeks 1-2 stand up + review, weeks 3-4 rebuild + first low-risk integrations, weeks 5-8 parallel run across production, weeks 9-10 full cutover, week 11+ export and decommission. That's on the faster end of the six-to-sixteen-week range other teams report generally, largely because the 1-click import removes the slowest part.

Why teams choose Regen over the JSM path

Regen has no per-seat pricing (free self-hosted, unlimited users), where JSM's tiers carrying the alerting features are priced per agent. Regen runs self-hosted, VPC, or air-gapped, which JSM doesn't offer. Regen includes AI-generated incident post-mortems (BYOK: OpenAI, Anthropic, Ollama), which isn't part of what's moving into JSM.

FAQ

Do we have to migrate before April 5, 2027? Yes, in the sense that data is deleted on that date. Start with enough runway for a parallel run, six to ten weeks minimum.

Can we run Regen and Opsgenie at the same time? Yes, that's the recommended path here.

Does the migration bring over incident history? No, live configuration only. Export history separately.

What if we have heavily customized routing rules? Budget time to rebuild those manually, typically the longest step.

Getting started

Stand up FluidifyAI Regen self-hosted for free, or on Managed Cloud starting at $100/month, and run the migration against a read-only Opsgenie integration key to see what transfers before committing to anything. Talk to us if you want a second pair of eyes on the plan.

10 Best Open-Source On-Call Management Tools

Yathartha Shekhar — Tue, 22 Sep 2026 04:41:57 +0000

Cross-posted from the Fluidify blog. Disclosure: I work on FluidifyAI Regen, one of the tools below.

Most lists of "open-source on-call tools" mix genuinely different categories: full scheduling-plus-escalation platforms, alert routers that assume you bring your own scheduling, and monitoring systems with paging bolted on. Worth separating before picking one, which is what this list does.

Of the ten below, FluidifyAI Regen is the one I'd point a team at if the goal is one self-hosted tool instead of stitching together two or three: it's the only entry that covers scheduling, escalation, and incident coordination together, actively developed, no per-seat pricing.

What "open-source on-call tool" actually covers

Scheduling + escalation platforms manage who's on call, rotate them, and escalate a page through a policy until someone acknowledges it.
Alert routers take signals from monitoring systems, deduplicate and classify them, and decide who or what gets notified, without necessarily owning the schedule itself.
Monitoring systems with alerting built in generate the signals in the first place and can notify people directly, but weren't built primarily as on-call platforms.

Quick comparison

Tool	License	Category	Scheduling	Escalation	Incident coordination	Status (2026)
FluidifyAI Regen	AGPLv3	Full platform	Yes	Yes	Yes, with AI post-mortems	Active
GoAlert	Apache-2.0	Scheduling + escalation	Yes	Yes	No	Active
LinkedIn Oncall + Iris	Apache-2.0	Scheduling + escalation (2 repos)	Yes	Yes	No	Low activity
Keep	AGPLv3/MIT (mixed)	Alert router / AIOps	Basic	Workflow-based	Partial	Active
Alerta	MIT	Alert router	No	No	No	Low activity
Grafana OnCall	Apache-2.0	Scheduling + escalation	Yes	Yes	No	Archived March 2026
Cabot	MIT	Monitoring + alerting	No	Basic	No	Dormant
Prometheus Alertmanager + Karma	Apache-2.0	Alert router	No	Routing rules	No	Active
Zabbix	GPLv2	Monitoring + alerting	No	Escalation trees	No	Active
Icinga 2	GPLv2	Monitoring + alerting	No	Notification rules	No	Active

1. FluidifyAI Regen

Category: full platform. Perfect for: teams that want scheduling, escalation, and incident coordination in one self-hosted tool without stitching together two or three open-source projects.

Notable features

Alert ingestion from Prometheus Alertmanager, Grafana, AWS CloudWatch, or a generic webhook, with pattern matching that learns from historical incidents.
On-call scheduling with layer-based rotations, overrides, holidays, exceptions, and leave, with timezone and multi-language support.
Multi-step escalation policies with configurable timeouts per step.
Immutable incident timelines with bidirectional Slack and Microsoft Teams sync, including bot commands and Adaptive Cards.
AI-generated incident summaries and post-mortems, bring-your-own-key with OpenAI, Anthropic, or Ollama.
Free SSO/SAML on the self-hosted tier.
One-click migration from Grafana OnCall, Opsgenie (sunsetting April 2027), or PagerDuty.

Where it falls short: a fuller platform than teams who just want a minimal scheduling-and-paging backbone need, with more moving parts to run than GoAlert's single-binary footprint.

Pricing: free under AGPLv3 self-hosted, unlimited users and schedules. Managed Cloud starts at $100/month (Pro), $200/month (Business). Enterprise is a custom contract for SCIM, audit logs, and SOC 2 requirements. Full pricing breakdown.

Source and docs: github.com/FluidifyAI. For the fuller picture, see What Is FluidifyAI Regen?

2. GoAlert

Category: scheduling + escalation. Perfect for: teams that want a minimal, self-hosted paging backbone and are comfortable building incident coordination separately.

Notable features: built by Target's engineering team, ships as a single Go binary with a PostgreSQL backend. Handles rotations, escalation policies, and multi-channel notification (voice, SMS, push) cleanly.

Where it falls short: no incident coordination layer, no timeline, no post-mortem tooling. Voice and SMS require your own Twilio account with real credentials; if misconfigured, notification rules can silently fail to fire rather than erroring loudly.

Pricing: free, self-hosted only, no managed offering.

3. LinkedIn Oncall + Iris

Category: scheduling + escalation, split across two repositories. Perfect for: teams with the engineering capacity to integrate and operate two separate open-source projects for the sake of using something battle-tested at LinkedIn's scale.

Notable features: Oncall handles the scheduling calendar, including follow-the-sun rotations. Iris is the escalation engine, built to process very high message volume reliably.

Where it falls short: the two projects need to be wired together and operated as separate services, and community activity has slowed considerably since their initial release.

Pricing: free, self-hosted only.

4. Keep

Category: alert router / AIOps. Perfect for: teams whose main pain point is too many duplicate and unrelated alerts arriving from multiple monitoring sources.

Notable features: correlates and deduplicates alerts across sources, with workflow automation that can trigger notifications, tickets, or other actions.

Where it falls short: on-call scheduling is present but secondary to its correlation and workflow features.

Pricing: free, open-source, with a hosted option available.

5. Alerta

Category: alert router. Perfect for: teams that already have scheduling and escalation solved elsewhere and just need a central place to route alerts.

Notable features: a clean, purpose-built alert management API and UI that many other tools integrate with as a routing layer.

Where it falls short: no scheduling or escalation of its own.

Pricing: free, self-hosted only.

6. Grafana OnCall

Category: scheduling + escalation. Status: archived: Entered maintenance mode in 2025, formally archived March 2026. Existing deployments keep running with no ongoing development.

Notable features (historical): tight integration with Grafana dashboards and alerting.

Where it falls short now: it's the reason this list exists in its current form.

Pricing: free, self-hosted, archived.

7. Cabot

Category: monitoring + alerting. Perfect for: small teams that want a lightweight, self-hosted check-and-alert system.

Notable features: built by Arachnys as a self-hosted alternative combining Nagios-style checks with a paging layer.

Where it falls short: development activity has been minimal for an extended period; verify current maintenance status before depending on it.

Pricing: free, self-hosted only.

8. Prometheus Alertmanager + Karma

Category: alert router. Perfect for: teams already running Prometheus who need alert grouping, silencing, and routing with a usable dashboard.

Notable features: Alertmanager's routing tree and silencing are mature; Karma adds a much more usable interface for triaging active alerts.

Where it falls short: doesn't schedule who's on call or manage escalation timeouts on its own.

Pricing: free, self-hosted, part of the CNCF ecosystem.

9. Zabbix

Category: monitoring + alerting. Perfect for: infrastructure teams that want monitoring and basic escalation in one system.

Notable features: mature monitoring platform with configurable escalation trees.

Where it falls short: no shift rotation concept, no override handling, no incident timeline.

Pricing: free, open-source, GPLv2.

10. Icinga 2

Category: monitoring + alerting. Perfect for: teams already invested in the Nagios/Icinga ecosystem.

Notable features: flexible notification rules tied to host and service checks, mature plugin ecosystem.

Where it falls short: monitoring-native alerting rather than dedicated scheduling and escalation.

Pricing: free, open-source, GPLv2.

FAQ

Why is FluidifyAI Regen the top pick on this list? It's the only entry that covers scheduling, escalation, and incident coordination, with AI-generated post-mortems, in one self-hosted, actively developed package and no per-seat pricing.

Which has the lowest operational overhead to self-host? GoAlert, by design: a single binary plus PostgreSQL. Regen and Keep are close behind.

Can I combine an alert router like Alerta or Karma with GoAlert? Yes, common pattern: dedup/classify upstream, then hand off to a scheduling-and-escalation tool.

What's the best open-source replacement for Grafana OnCall now that it's archived? FluidifyAI Regen and GoAlert are the two actively maintained full or near-full alternatives. Grafana OnCall itself will keep running if already deployed, but with no security patches or bug fixes coming, plan a migration on your own timeline.

Choosing between them

If the goal is one self-hosted tool covering scheduling, escalation, and incident response, FluidifyAI Regen and GoAlert are the two to evaluate first. If you're migrating off an archived or sunsetting platform, Regen's 1-click migration from Grafana OnCall, Opsgenie, and PagerDuty is worth checking. If you also want commercial platforms in the comparison, see our broader best on-call management tools for 2026.

Escalation Policies as Code: On-Call Rotations in Git

Yathartha Shekhar — Fri, 18 Sep 2026 06:11:33 +0000

Cross-posted from the Fluidify blog.

Ask most teams who's allowed to change an escalation policy, and the honest answer is "whoever has admin access and remembers to." The policy that decides who gets woken up at 3 a.m., and how fast, typically lives entirely inside a vendor's web UI: click into a policy, adjust a timeout, save. No review, no diff, no record of why the timeout went from five minutes to ten, and no way to see what the policy looked like six months ago short of asking whoever made the change, if they still remember.

This is the same problem infrastructure had before Terraform: configuration that only exists as the current state of a system, changeable by anyone with access, with history that lives in people's memory instead of a repository. The fix there was treating infrastructure as code. The same fix applies to on-call config, and for the same reason: escalation policies and schedules are operational logic, not administrative settings, and operational logic that can silently change without review is a real risk during an actual incident, and a quiet contributor to alert fatigue months later when nobody remembers why a timeout is set the way it is.

The pattern

The shape is the same as any other infrastructure-as-code setup: a directory of declarative files, a tool that reconciles them against the live system, and a CI pipeline that runs that tool on merge.

oncall/
  schedules/
    payments-primary.yaml
    payments-secondary.yaml
    infra-oncall.yaml
  escalation-policies/
    payments-outage.yaml
    infra-warning.yaml
  integrations/
    prometheus-payments.yaml
    cloudwatch-infra.yaml

A schedule file might look like:

# schedules/payments-primary.yaml
name: payments-primary
timezone: America/New_York
rotation:
  type: weekly
  handoff: monday 09:00
participants:
  - alice@company.com
  - bob@company.com
  - carla@company.com
overrides:
  - date: 2026-12-24
    user: dave@company.com
    reason: holiday coverage swap

And an escalation policy:

# escalation-policies/payments-outage.yaml
name: payments-outage
severity: critical
steps:
  - after: 0m
    notify: schedule:payments-primary
  - after: 5m
    notify: schedule:payments-secondary
  - after: 15m
    notify: user:eng-manager@company.com
    channel: phone

Nothing here is exotic. It's the same declarative-config idea applied to a domain that mostly hasn't gotten it yet.

What you actually gain

Review before it's live: A change to a critical escalation policy goes through a pull request like any other production change. A reviewer can catch "this removes the secondary on-call from the payments policy" before it ships, not after an incident reveals it.

A real audit trail: git blame on an escalation policy answers "who changed this and why" in one command, with the linked PR and its discussion attached.

Rollback: Revert the commit, re-apply, done.

Disaster recovery for the on-call config itself: If the on-call platform loses data or an account gets locked out, the entire schedule and escalation setup can be rebuilt from a git checkout.

What's still missing

The gap in this pattern today isn't tooling to declare the config, it's tooling to validate it before it's live. Terraform can plan a diff and show you what will change, but it can't tell you that a proposed escalation policy would have caused an on-call engineer to get skipped during last month's actual incident. Policy simulation, replaying a set of historical alerts against a proposed policy change, is close to nonexistent across the ecosystem right now.

The other open problem is drift. If someone edits a schedule directly in the vendor UI during an incident (which will happen, and should be allowed to happen), the git state and the live state disagree until someone reconciles them. Few setups have automated drift detection for on-call config the way they do for infrastructure.

Existing building blocks

Terraform has official or community providers for several on-call and incident platforms, letting you declare schedules and escalation policies as Terraform resources and manage them through a normal plan/apply workflow. Where a provider doesn't exist, the fallback is a sync script: read the YAML, diff it against the platform's REST or GraphQL API, apply the difference, run it in CI on merge to main.

If you're evaluating on-call tools with this pattern in mind, check whether the platform exposes full API coverage over schedules, escalation policies, and integrations, and whether you can inspect the underlying data model directly if you're self-hosting it. That's part of why we designed FluidifyAI Regen as open-source and API-first, with the source and API reference on GitHub.

If you haven't settled on a platform yet, our rundown of open-source on-call tools is worth a read before you pick one to build this pattern on top of.

FAQ

Do we need a custom sync script if a Terraform provider already exists? No, use the provider. Reach for a sync script only when no provider covers what you need.

What about changes made during an actual incident? Let them happen directly in the tool. Reconcile afterward: either update the git source to match, or revert the live change back once the incident is over.

Is this worth it for a five-person team? The audit trail and rollback value scale with team size, but even a small team benefits from "why does this escalation policy skip Tuesdays" having an answer in git history.

Where this is heading

Policy simulation is the missing piece that would make this pattern complete: replay real alert history against a proposed change and see the difference before merging, the way terraform plan shows an infrastructure diff before apply. Nobody has shipped this well yet across the ecosystem. It's the natural next step for whichever platform builds it first.

Why Alert Fatigue Survives Every Tooling Migration

Yathartha Shekhar — Mon, 14 Sep 2026 10:59:18 +0000

Cross-posted from the Fluidify blog.

Every few years, a team gets tired of drowning in pages and migrates to a new on-call tool. The rollout goes fine. Schedules import cleanly, integrations reconnect, everyone gets a shiny new mobile app. Then, somewhere between four and twelve weeks later, the same on-call engineer who pushed for the migration is back to muting notifications at 2 a.m. and triaging the same noisy alert they were triaging on the old platform.

This isn't a failure of the new tool. It's what happens when a team changes where the alerts land without changing what causes them to fire in the first place. The rules that produced fatigue on the old system, which alerts get created, how they escalate, who they wake up, come across in the migration as faithfully as the schedules do. A new UI on top of the same rules produces the same outcome with a different logo.

What actually causes alert fatigue

Three root causes show up in almost every team that reports fatigue, regardless of which tool they're on:

Noisy sources with no classification layer. Most alerting pipelines treat every signal from Prometheus, CloudWatch, or a health check as equally worth a human's attention. A flapping check that recovers in ninety seconds pages the same way a full outage does. Without deduplication and severity classification at the point alerts are generated, the on-call engineer becomes the classification layer, by hand, every single time.

Escalation policies that don't differentiate urgency. A five-minute escalation timeout makes sense for a payment outage. It does not make sense for a disk-usage warning that can wait until morning. When every alert type shares one escalation policy, either the urgent stuff waits too long or the routine stuff interrupts sleep, and teams routinely get this backwards in both directions on the same policy.

No owner for alert hygiene. Someone has to look at the alerts that fired last week, decide which ones were useful, and either fix, downgrade, or delete the ones that weren't. In most teams, nobody owns this. It falls to whoever happens to be on-call when they get frustrated enough, which means the noisy alert survives until someone has a bad week and finally kills it out of spite. That's not a process, and it doesn't scale.

Why a new tool doesn't fix any of the three

None of those three causes live in the vendor. Classification, escalation policy design, and hygiene ownership are decisions a team makes and re-makes, and a tool migration is exactly the moment those decisions get carried over unexamined, because reproducing the existing setup quickly is the whole point of a smooth migration. The team optimizes for "nothing broke" and, in doing so, optimizes for "nothing changed," including the parts that were broken.

The tools also look similar enough on this specific axis that switching between them rarely forces the issue. Every mainstream on-call platform supports severity levels, deduplication rules, and tiered escalation. The gap isn't feature availability. It's that configuring those features well takes an audit most teams skip during a migration.

If a migration is already on the table, it's worth doing the audit below before comparing vendors, not after.

What actually works

The interventions that measurably reduce fatigue touch the three root causes directly, independent of vendor:

Classify and deduplicate at the source, not at the human. Group alerts from the same root cause into one notification. Suppress known-flapping checks instead of paging on every transition. This is configuration work on the monitoring side (Alertmanager routing rules, Grafana notification policies) as much as the on-call tool.

Match escalation speed to actual urgency, per alert type, not per team. A payment-path outage and a disk-warning should never share an escalation policy. Once that logic is right, managing it as version-controlled config instead of a vendor UI setting is what keeps it from drifting back.

Name an owner for alert hygiene, and give them a recurring slot. Someone reviews the last week or month of pages, tags what was noise, and has the authority to retune or delete rules without three approvals.

Close the loop after every incident. If a postmortem doesn't produce a concrete change to an alert rule or escalation policy when the alert was part of the problem, the same failure mode reappears with the label "known issue" attached to it.

A 30-day exercise that costs nothing

Before any team migrates on-call tools to solve fatigue, it's worth running this against the current one:

Pull every page from the last 30 days, grouped by alert rule.
For each rule, tag it: actionable, informational (nice to know, didn't need a wake-up), or noise (should never have paged).
For anything tagged noise, delete the rule, add deduplication, or move it off the paging path entirely.
For anything tagged informational, move it to a lower urgency tier with a slower escalation.
For actionable pages, check that the escalation timeout matches how much time the team actually has before impact grows.

Most teams find that a third to half of their pages fall into noise or informational once they actually look, on the tool they already have. If fatigue is still there after that exercise, a new tool might genuinely help.

FAQ

Does a better on-call tool ever fix alert fatigue? It can remove friction around fixing it, but the tool doesn't do the classification or ownership work for you.

How do we know if our escalation policies are the problem? Check how many pages resolved themselves or were ignored until auto-resolve, versus how many required real action within the escalation window. A high self-resolving ratio usually means the timeout is too aggressive.

Who should own alert hygiene without a dedicated SRE team? Rotate it with the on-call schedule: whoever was on-call last week reviews last week's pages before handing off.

I build FluidifyAI Regen, an open-source on-call and incident tool, and this exact pattern is why its AI-generated post-mortems flag the specific alert rules involved in an incident rather than just summarizing what happened. A tool can make the hygiene work faster to do. It can't do the work of deciding what deserves a human's sleep for you.

What Is FluidifyAI Regen? The Best On-Call and Incident Management Tool for 2026

Yathartha Shekhar — Wed, 09 Sep 2026 12:50:02 +0000

Cross-posted from the Fluidify blog. Disclosure: I work on FluidifyAI Regen.

FluidifyAI Regen is an open-source (AGPLv3) on-call and incident management tool. You run it from a single Docker Compose file, point Alertmanager or Grafana at it, and get schedules, escalation, an immutable incident timeline, and AI-written post-mortems. There is no per-seat pricing on any tier, and no cap on users, incidents, or schedules.

This is a plain overview of what it does and how the three deployment models differ.

Run it three ways

Self-hosted, open source

The community edition is AGPLv3. Docker Compose or Kubernetes, up in under five minutes. Unlimited users, incidents, and schedules. SSO/SAML, Slack, Microsoft Teams, Telegram, mobile push, and BYO-LLM AI post-mortems are all included, not gated behind a paid tier.

Managed SaaS

Same feature surface as self-hosted, plus the dedicated iOS/Android on-call app with Twilio phone calls, RBAC, custom fields, and the multi-language interface. Free for 30 days, then $100/month (Pro) or $200/month (Business). Neither plan charges per user.

Enterprise on your own infrastructure

Forward Deployment Engineers stand up the stack on-prem, in a private VPC, or fully air-gapped, for teams that cannot send incident data to a hosted service.

What it does

Alert ingestion and routing

Ingests from Prometheus Alertmanager, Grafana, AWS CloudWatch, and a generic webhook, plus more. Pattern matching learns from historical incidents, so recurring alerts get recognized and routed without you rebuilding the rule each time.

On-call schedules

Rotations and overrides, with holidays, exceptions, and leave as first-class concepts rather than manual swaps. Global timezone support shows each person their own local hours on a follow-the-sun rotation. Interface available in multiple languages, including Chinese and Spanish.

Escalation policies

Multi-step escalation with per-step timeouts. No acknowledgement inside the window, it moves to the next person or team automatically.

Incident lifecycle with an immutable timeline

Every incident runs through a defined lifecycle with a commander assigned at creation. The timeline is immutable: every acknowledgement, status change, note, and Slack message is recorded in order and cannot be edited after the fact. That is what makes the post-mortem trustworthy and the audit trail real.

Slack and Microsoft Teams

Bidirectional sync with both. Slack gets channels, bot commands, and timeline sync. Microsoft Teams gets Adaptive Cards and bot commands. Actions taken in chat land on the incident timeline, and incident updates show up in chat.

AI post-mortems and digests

Generates incident summaries, post-mortems, and shift-handoff digests from the timeline, then posts them to Slack or Teams. It uses a model key you bring: OpenAI, Anthropic, or a local Ollama instance. Your incident data goes to the provider you choose, or stays on your own hardware with Ollama. Included on every tier, self-hosted build included.

Notifications

Telegram and mobile push for Android and iOS via Firebase Cloud Messaging on every tier. Managed SaaS and Enterprise add the dedicated on-call app and Twilio phone calls.

Identity

SSO/SAML 2.0 with Okta, Azure AD, Google Workspace, or any compliant IdP. On the free tier, not held back for a paid one.

What each deployment includes

Capability	Self-hosted OSS	SaaS	Enterprise
No limits on users, incidents, schedules, AI	Yes	Yes	Yes
Incident lifecycle with immutable timeline	Yes	Yes	Yes
Escalation policies with multi-step timeouts	Yes	Yes	Yes
Alert ingestion: Prometheus, Grafana, CloudWatch, webhook	Yes	Yes	Yes
Pattern matching and learning from historical incidents	Yes	Yes	Yes
Schedules, rotations, overrides, holidays, leave	Yes	Yes	Yes
Global timezone support	Yes	Yes	Yes
SSO / SAML 2.0	Yes	Yes	Yes
Slack integration	Yes	Yes	Yes
Microsoft Teams integration	Yes	Yes	Yes
AI summaries, post-mortems, handoff digests	Yes	Yes	Yes
BYO LLM key: OpenAI, Anthropic, Ollama	Yes	Yes	Yes
Telegram notifications	Yes	Yes	Yes
Mobile push, Android and iOS via FCM	Yes	Yes	Yes
Multi-language interface	No	Yes	Yes
Dedicated iOS/Android on-call app	No	Yes	Yes
Twilio call support	No	Yes	Yes
RBAC and custom fields	No	Yes	Yes
Full integration stack	Limited	Complete	Complete
On-prem, private VPC, or air-gapped deployment	Self-managed	No	Yes
Custom SSO / SCIM, redaction, MFA, audit logs and traces	No	No	Yes

No per-seat pricing

Every SaaS competitor in this category charges per user or per responder: PagerDuty, incident.io, Opsgenie, xMatters, FireHydrant, Rootly, Splunk On-Call, Squadcast, HyperPing, and Grafana OnCall. At a 100-engineer team, that difference is worth an estimated $50k per year for Regen alone. Treat that as an estimate tied to a 50 to 60 member team size. The self-hosted edition has no seat limit and no billing attached to it at all.

Who it fits

Teams whose on-call bill scales with headcount. Paying per responder for PagerDuty, Opsgenie, incident.io, or similar, and the gap grows with every hire.
Slack-first or Teams-first incident response. The response happens in chat and the timeline stays accurate without anyone copying updates back and forth.
Teams that stopped writing post-mortems because nobody has time. Regen drafts them from the immutable timeline.
Enterprises with air-gap or compliance requirements: SOC 2, HIPAA, GDPR, the EU AI Act, DPDPA.

Poor fit: solo developers or hobby projects with no rotation, or teams that want their observability platform and their on-call tool to be the same product. Regen does on-call and incident management and integrates with the monitoring you already run.

Compliance

Built to SOC 2, GDPR, DPDPA, EU AI Act, and HIPAA guidelines. The Enterprise tier adds custom SSO and SCIM provisioning, redaction protocols, MFA, and audit logs with traces. The air-gapped deployment exists for teams that cannot send incident data to a hosted service under any circumstances.

FAQ

Is Regen open source? Yes. The self-hosted community edition is AGPLv3.

Is there a free version? Two. The self-hosted build is free permanently. The managed SaaS is free for the first 30 days.

Does the free tier include AI features? Yes. BYOK AI post-mortems and summaries are in the self-hosted build. Higher-volume managed AI features scale by paid tier via credits.

Can I self-host? Yes. Docker Compose or Kubernetes, under five minutes. Unlimited users, incidents, and schedules.

Does Regen do root cause analysis or auto-remediation? No. Regen owns on-call and incident coordination. Root cause analysis is Neuri, auto-remediation is Reflex. Both are part of the same suite.

What does Regen replace? PagerDuty, Grafana OnCall, Opsgenie, incident.io, FireHydrant, Better Stack, Splunk On-Call, Squadcast, xMatters, and Rootly.

How do I move existing schedules over? 1-click migration imports schedules and escalation policies from Grafana OnCall, Opsgenie, or PagerDuty.

Try it

Start the 30-day Pro trial for the hosted version, or clone the open-source repo and run the Docker Compose file against your own Alertmanager. The pricing page has the numbers at your team size, and contact us for on-prem, private VPC, or air-gapped deployment.

Top 4 Hyperping Alternatives for 2026

Yathartha Shekhar — Sat, 05 Sep 2026 11:15:25 +0000

Key takeaways

Hyperping bundles monitoring, on-call, and status pages at flat, per-monitor pricing. That's cheaper than per-seat competitors, but the on-call side stops at a fixed escalation chain: no rotation scheduling, no incident timeline, no AI.
FluidifyAI Regen picks up exactly that gap: on-call scheduling, incident coordination, and AI-generated post-mortems, with no per-seat pricing either.
Regen doesn't do uptime or synthetic monitoring itself. It ingests alerts from whatever monitoring you already run, so keep Hyperping (or anything else) for checks and add Regen for what happens after an alert fires.

Why teams look for Hyperping alternatives

Hyperping's flat, per-monitor pricing is a real advantage over per-seat competitors. A 50-person team costs the same as a 5-person one. But the product stops at getting someone paged. There's no incident timeline, no root cause layer, no AI-assisted post-mortem, and escalation is a fixed chain instead of layered rotations with overrides for holidays or leave. Teams that outgrow "notify someone" and need actual incident coordination look elsewhere.

Top picks at a glance

Best overall: FluidifyAI Regen. Layer-based on-call scheduling, incident coordination, and AI-generated post-mortems, with no per-seat pricing, covering exactly the on-call gap in Hyperping's bundle.

Quick comparison

Tool	Starting price	On-call / escalation	AI post-mortems	Self-hosted
FluidifyAI Regen	Free (AGPLv3), $100/mo managed	Layer-based rotations, multi-step escalation	Yes, included	Yes
Hyperping (current)	Free to $249/mo flat	Fixed escalation chains	No	No
Better Stack	Free tier, on-call from $29/responder/mo	Yes	No (investigation, not post-mortems)	No
PagerDuty	About $21/user/mo	Yes, mature	No	No
UptimeRobot	$9 to $69/mo (annual)	Alert delivery only, no scheduling	No	No

1. FluidifyAI Regen

Multi-step escalation policies with configurable timeouts.

Perfect for: teams that have outgrown Hyperping's fixed escalation chain and want real on-call scheduling, incident coordination, and a post-mortem that writes itself, without per-seat pricing.

Notable features

On-call scheduling with layer-based rotations, overrides, holidays, exceptions, and leave. Hyperping doesn't offer rotation scheduling, just escalation chains
Escalation policies with multi-step timeouts
Immutable incident timelines with bidirectional Slack and Microsoft Teams sync
AI-generated incident summaries, post-mortems, and handoff digests, using your own model key. BYOK with OpenAI, Anthropic, or Ollama
Alert ingestion from Prometheus Alertmanager, Grafana, AWS CloudWatch, or a generic webhook. Bring your own monitoring, since Regen doesn't do uptime checks
SSO/SAML 2.0 included on the free tier
1-click migration from Grafana OnCall, Opsgenie or PagerDuty

Why Regen over Hyperping

Hyperping is monitoring-first with basic paging attached. Regen is incident-management-first, built to sit on top of whatever monitoring you already run, including Hyperping itself, via webhook. If you've outgrown Hyperping's on-call side specifically, no rotation scheduling, no incident timeline, no AI post-mortem, Regen is a direct upgrade on exactly that part, without forcing you to also replace your monitoring. See the full feature list.

Where it falls short

No synthetic uptime monitoring or public status pages, that's Hyperping's core product; Regen picks up after an alert already exists, not before.

Pricing

Free under AGPLv3 for the self-hosted tier: unlimited users, incidents, and schedules, includes SSO/SAML and BYOK AI. Managed Cloud starts at $100/month (Pro) and $200/month (Business, which adds Reflex and Gills on top of Regen and Neuri). Enterprise is a custom annual contract. No per-user pricing on any tier. Full pricing breakdown if you want the numbers at your own team size.

Choose Regen if: you want to keep whatever monitoring you're already running and add real on-call scheduling, incident coordination, and AI post-mortems on top of it.

2. Better Stack

Also considered: teams comparing Hyperping's bundle against a heavier observability platform that also happens to include on-call.

Notable features

Combined logs, metrics, traces, uptime monitoring, and on-call in one platform
AI-assisted root cause investigation using native telemetry
Built-in status pages and incident communication

Where Better Stack fits, and where Regen still wins

Better Stack goes considerably deeper on observability than Hyperping: logs, infrastructure monitoring, and an AI investigation agent, at a price that reflects that depth. None of that changes the on-call story. Escalation is still billed per-responder, and the AI output is investigation, not the AI-generated post-mortem Regen includes on every tier including the free one.

Where it falls short

Free tier is capped tightly, 10 monitors, 3GB logs, and costs rise once you outgrow it. No self-hosted option. On-call pricing is per-responder, unlike Hyperping's or Regen's models.

Pricing

Free tier for small-scale use. Paid plans with on-call start at $29/responder/month.

Choose Regen instead if: you want on-call and incident coordination handled properly without paying for Better Stack's bundled observability just to get better paging.

3. PagerDuty

Also considered: teams that have fully outgrown Hyperping's scope and assume the only step up is the most established name in on-call.

Notable features

On-call scheduling and escalation policies
Broad third-party integration ecosystem
AIOps and Advance tiers as separate add-on products

Where PagerDuty fits, and where Regen still wins

PagerDuty is a dedicated, enterprise-grade on-call platform with none of Hyperping's monitoring or status-page scope, same as Regen. What it adds over Regen is a longer track record in enterprise on-call specifically, at per-seat pricing that compounds with every hire and with no AI-generated post-mortems included at any tier.

Where it falls short

Per-seat pricing that compounds with every hire, the opposite of Hyperping's flat model. No self-hosted option. No AI-generated post-mortems.

Pricing

Starts at about $21/user/month, with AIOps and Advance sold as separate add-ons.

Choose Regen instead if: you want PagerDuty's dedicated on-call focus without the per-seat bill or the missing AI post-mortems.

4. UptimeRobot

Also considered: teams comparing Hyperping's monitoring specifically against a cheaper, monitoring-only tool.

Notable features

HTTP(S), keyword, ping, port, and heartbeat/cron monitoring
Alerts via email, SMS, voice, push, and integrations including Slack, Teams, Discord, and PagerDuty
Free tier with 50 monitors at 5-minute intervals

Where UptimeRobot fits, and where Regen still wins

UptimeRobot's free tier is more generous for pure monitoring than Hyperping's paid entry point. But it only delivers alerts, no on-call scheduling, no escalation, no incident timeline, no coordination once something breaks. That's the gap Regen fills on top of it, at no per-seat cost either.

Where it falls short

No on-call scheduling, escalation policies, or incident coordination, alert delivery only. No AI of any kind. No status pages on the free tier.

Pricing

Free tier, 50 monitors, 5-minute intervals. Paid: Solo about $9/month, Team about $33/month, Enterprise about $69/month, annual billing.

Choose Regen alongside UptimeRobot if: monitoring is one gap and on-call or incident coordination is the other, since UptimeRobot doesn't do either.

FAQ

What's the best Hyperping alternative overall? FluidifyAI Regen, for the on-call and incident coordination half of Hyperping's bundle: real rotation scheduling, an incident timeline, and AI post-mortems, none of which Hyperping's fixed escalation chains do, with no per-seat pricing either.

Does Regen replace Hyperping's monitoring checks? No, and it doesn't need to. Regen ingests alerts from whatever monitoring you already run, Hyperping, Prometheus, Grafana, CloudWatch, or a generic webhook, and handles everything after the alert fires: paging, escalation, coordination, and the post-mortem. That's the part of Hyperping's bundle actually worth replacing.

Is there a free alternative to Hyperping? FluidifyAI Regen is free under AGPLv3 for the self-hosted community tier, with no seat limits, though it doesn't include monitoring checks.

Why does Hyperping's on-call feel limited compared to dedicated tools? Because on-call is one piece of a broader monitoring bundle, not the core product. Hyperping ships fixed escalation chains rather than the layered rotation scheduling, overrides, and incident timelines a dedicated tool like Regen builds specifically for on-call, with AI-generated post-mortems on top.

Moving your on-call off Hyperping

You don't have to touch your monitoring setup to do this. Point Hyperping's webhooks (or Prometheus, Grafana, CloudWatch, whatever you're actually running) at Regen, set up rotations and escalation policies, and Hyperping keeps doing checks while Regen handles what happens when one fails. The self-hosted version is on GitHub if you want to run it locally first, or talk to us if you'd rather walk through your setup directly.

Top 4 xMatters Alternatives for 2026

Yathartha Shekhar — Sat, 05 Sep 2026 11:00:49 +0000

Key takeaways

xMatters connects incidents to the rest of your operational tooling through 200+ integrations. That automation depth costs configuration time and per-seat pricing that most teams never fully use.
FluidifyAI Regen covers the on-call and incident coordination work every team actually does, with no per-seat pricing, a self-hosted option, and AI-generated post-mortems included.

Why teams look for xMatters alternatives

Most teams set up xMatters for on-call scheduling, escalation, and maybe a handful of integrations. Then they get a bill sized for the full 200-integration platform. The gap between what a team configures and what it pays for is the most common reason to look elsewhere. Per-seat pricing means that gap grows every time you hire, regardless of how much of the automation surface you're using.

Top picks at a glance

Best overall: FluidifyAI Regen. Full incident lifecycle, AI post-mortems, no per-seat pricing, self-hosted or SaaS.

Quick comparison

Tool	Starting price	Self-hosted	AI post-mortems	Per-seat pricing
FluidifyAI Regen	Free (AGPLv3), $100/mo managed	Yes	Yes, included	No
xMatters (current)	About $9/user/mo	No	No	Yes
PagerDuty	About $21/user/mo	No	No	Yes
Opsgenie	About $9.45/user/mo	No	No	Yes
incident.io	$15 to $19/user/mo, on-call billed separately	No	No	Yes

1. FluidifyAI Regen

Alert ingestion and routing from Prometheus, Grafana, CloudWatch, or a generic webhook.

Perfect for: teams that want the on-call and incident coordination part of xMatters without paying for or configuring the automation surface they never touch.

Notable features

Alert ingestion from Prometheus Alertmanager, Grafana, AWS CloudWatch, or a generic webhook, with pattern matching that learns from historical incidents
On-call scheduling with layer-based rotations, overrides, holidays, exceptions, and leave. Global timezone and multi-language support
Escalation policies with multi-step timeouts
Immutable incident timelines with bidirectional Slack and Microsoft Teams sync: channels, bot commands, and Adaptive Cards
AI-generated incident summaries, post-mortems, and handoff digests, using your own model key. BYOK with OpenAI, Anthropic, or Ollama
SSO/SAML 2.0 with Okta, Azure AD, Google Workspace, or any compliant IdP, included on the free tier
1-click migration from Grafana OnCall, Opsgenie or PagerDuty

Why Regen over xMatters

xMatters' automation depth is real, but most teams use a fraction of its 200 integrations. Regen handles the part every team actually uses, on-call and incident coordination, without per-seat pricing, and adds AI-generated post-mortems xMatters doesn't have. It also deploys self-hosted, VPC, or air-gapped, which xMatters doesn't offer at any price. Full deployment details are on the Regen product page.

Where it falls short

Built for the incident and on-call stack specifically, not xMatters' broader enterprise workflow and ITSM connector marketplace: different scope, not a smaller one.

Pricing

Choose Regen if: your xMatters bill is driven by headcount rather than actual automation usage, or you need a self-hosted deployment xMatters doesn't provide.

2. PagerDuty

Also considered: large organizations comparing xMatters against the most established name in on-call.

Notable features

Mature on-call scheduling and escalation policies
Broad third-party integration ecosystem
AIOps and Advance tiers as separate add-on products

Where PagerDuty fits, and where Regen still wins

PagerDuty has a longer track record and broader integration ecosystem than xMatters, usually at a higher per-seat cost than either xMatters or Regen. It adds none of Regen's AI-generated post-mortems and no self-hosted option, at a price that climbs the same way xMatters' does.

Where it falls short

Per-seat pricing that compounds with every hire, typically more expensive than xMatters at the same headcount. No self-hosted option. No AI-generated post-mortems.

Pricing

Starts at about $21/user/month, with AIOps and Advance sold as separate add-ons.

Choose Regen instead if: you want the most established category's core job done, on-call and escalation, without the per-seat bill or the missing AI post-mortems.

3. Opsgenie

Also considered: teams standardized on Atlassian tooling comparing xMatters against Atlassian's own on-call product.

Notable features

On-call scheduling and escalation policies
Native Jira Service Management integration
Alert deduplication and routing rules

Where Opsgenie fits, and where Regen still wins

Opsgenie's Atlassian integration is deeper than what xMatters offers as a general-purpose automation platform, and Regen's SSO/SAML works with any Atlassian identity setup just the same. Opsgenie still bills per seat and has no AI-generated post-mortems, the same two gaps xMatters has. Regen's 1-click migration covers Opsgenie directly if you're moving off it.

Where it falls short

Integrations outside the Atlassian ecosystem are noticeably shallower. No AI-assisted diagnosis or post-mortem generation. Per-seat pricing, same as xMatters.

Pricing

Free tier available. Paid plans start around $9.45/user/month.

Choose Regen instead if: your team runs on Atlassian tooling but doesn't want per-seat pricing or a post-mortem a human still has to write.

4. incident.io

Also considered: Slack-native teams comparing xMatters against a narrower coordination-first tool.

Notable features

Slack-native incident declaration, response coordination, and retrospectives
Automated status page updates tied to incident state
Post-mortem templates and automatic timeline construction

Where incident.io fits, and where Regen still wins

incident.io is narrower than xMatters by design: incident coordination inside Slack, not connecting incidents to a wide array of other systems. Regen syncs bidirectionally with Slack too, and includes on-call in the same price instead of billing it as a separate add-on, plus AI-generated post-mortems incident.io's templates don't produce.

Where it falls short

On-call scheduling isn't included. It's a separate add-on that adds $12 to $20/user/month on top of the base price. No AI-generated post-mortems, templates still require a human to fill them in. Per-user pricing scales with headcount the same way xMatters' does.

Pricing

Team plan from $15 to $19/user/month depending on billing term, plus roughly $12 to $20/user/month more for on-call. Enterprise is custom.

Choose Regen instead if: Slack-native coordination matters to your team, but you'd rather not pay for on-call separately or leave the post-mortem to a human.

FAQ

What's the best xMatters alternative? FluidifyAI Regen. It covers the on-call and incident coordination work every team actually uses, without per-seat pricing, without xMatters' unused automation overhead, and with AI-generated post-mortems included.

Is xMatters worth the automation complexity? For teams that use most of its 200 integrations to connect incidents into a broader operational workflow, yes. For teams that mainly use it to page people and coordinate a response, the automation surface goes unused, which is the gap Regen fills at a fraction of the cost.

What's the cheapest xMatters alternative? FluidifyAI Regen: free under AGPLv3 with no seat limits if self-hosting works for your team, and flat at $100/month managed if it doesn't. No other tool on this list avoids per-seat pricing.

Does any xMatters alternative include AI post-mortems? FluidifyAI Regen is the only one on this list with AI-generated post-mortems included at no extra cost. PagerDuty, Opsgenie, incident.io, and xMatters itself all leave the writeup to a human.

Migrating off xMatters

Regen's 1-click migration tooling covers Grafana OnCall, Opsgenie, and PagerDuty specifically, not xMatters yet. Moving off xMatters means recreating schedules and escalation policies directly in Regen's UI, which takes less time than most teams expect given how little of xMatters' surface most schedules actually use. The GitHub repo has the self-hosted setup docs if you want to run the numbers yourself before migrating a live rotation, or talk to us if you'd rather walk through it directly.