Opsgenie end of support: self-hosted alternatives

Opsgenie end of support: self-hosted alternatives for on-call teams

Opsgenie stops on April 5, 2027, and any data not migrated by then is deleted, so teams must choose a destination now. The two options are Atlassian's Jira Service Management path or a self-hosted tool. If your need is on-call alone, self-hosted GoAlert covers on-call schedules, rotations, escalation policies and notifications by SMS or voice, with Slack channels and email alerts as additional steps. It is Apache 2.0 licensed, ships as a single binary and needs PostgreSQL 17 or newer with the pgcrypto extension. Twilio is currently the only supported provider for SMS and voice, so plan that account, its costs and its sender setup as part of the project.

OneUptime suits teams that also want status pages, incident management and monitoring in one platform. Its Community Edition is Apache 2.0 licensed, except the ee/ directory, and it includes on-call schedules and escalation policies with alerts by SMS, phone call, push, email and Slack. It runs on Docker Compose on a single Debian, Ubuntu or RHEL server, or on the Helm chart the project recommends for production. Choosing it widens the migration beyond paging, so confirm which Opsgenie integrations and alert sources you depend on and whether OneUptime covers each one before you commit.

Export is the time-critical step on either path. Schedules, escalation policies, rotations and timeline history should be pulled out of Opsgenie while the account is still running, because anything left behind after April 5, 2027 is deleted. Start that work before designing the new system, then use the exported copies to rebuild rotations and test notifications. Confirm your Twilio or Slack credentials, your PostgreSQL hosting and a cutover window with the people who take pages, so the switch does not leave a gap in on-call coverage.

What the end-of-support deadline requires from your on-call stack

The shutdown turns on-call into a migration with a hard stop: schedules, escalation logic and alert sources have to be moved out of Opsgenie before unmigrated data is deleted. The cards below cover the work that connects export, rebuild, notification delivery and the secrets and logins the new system depends on.

Export schedules and escalation data

Pull schedules, rotations, escalation rules and timelines out of Opsgenie before the shutdown date, since unmigrated data is deleted on April 5, 2027. Schedules can be exported as iCalendar files, and timelines are retrieved through the Schedule API. Store the exports in your own repository with a dated inventory so each team can confirm what was captured before cutover.

Rebuild rotations and escalation policies

GoAlert models services, escalation policies, rotations and schedules, so each Opsgenie team needs to be recreated as those objects. Map every Opsgenie escalation step to a GoAlert equivalent, then check that the on-call person for each hour matches the old export. Treat the rebuilt configuration as the reference for the parallel test period.

Re-point alert sources

Every monitoring tool that pages through Opsgenie needs a new destination. GoAlert accepts alerts through a generic API, email, Grafana, Prometheus, Site24x7 and Sensu. List each integration in Opsgenie, confirm whether its source has a GoAlert alert source, and repoint the ones that do. Integrations without a matching source need a custom route or a different tool, which should be decided before cutover.

Keep notification delivery through a provider

Twilio is the only supported provider for GoAlert SMS and voice notifications, so the SMS and phone paths your on-call engineers rely on depend on a Twilio account you set up and pay for. Slack and email steps can also be escalation targets. Test each channel with real on-call contacts before cutover, and confirm current Twilio pricing with the provider rather than assuming it.

Protect the encryption key

GoAlert recommends setting a data encryption key so sensitive values such as API keys are encrypted before they reach the database. Every instance in a cluster must use the same key. Store it in your secrets manager, document the recovery path, and confirm that losing it would not leave the database unreadable. Include it in your backup and restore tests.

Control logins and the database

GoAlert supports GitHub OAuth and any OpenID Connect provider for login, with Dex suggested to bridge other identity systems. Connect it to your existing identity provider so access follows your joiner and leaver process. GoAlert's only hard requirement is PostgreSQL with the pgcrypto extension, and PostgreSQL 17 or newer is recommended for new installations, so the database needs its own backup, patching and high availability plan.

Jira Service Management, GoAlert and OneUptime compared

This table compares the three paths on the capabilities that matter when Opsgenie ends: on-call scheduling, escalation, notifications, login, hosting and license. Read the GoAlert and OneUptime columns against the trade-offs noted in each row, and confirm the Jira Service Management column directly with Atlassian, since no pricing or feature facts for that product were supplied here. The main takeaway is that the two self-hosted options differ mainly in notification providers and in which features sit behind an Enterprise license.

Capability	Jira Service Management	GoAlert (self-hosted)	OneUptime (self-hosted)
On-call scheduling	Atlassian's destination for Opsgenie customers. Confirm schedule and rotation features for your plan.	Schedules, rotations and calendar subscriptions are documented.	On-call schedules and escalation policies are included in the Community Edition.
Escalation	Escalation handling is part of the Atlassian product. Confirm the rules you need are supported.	Automated escalation policies are a core function.	Escalation policies are included. Confirm they cover your existing Opsgenie rules.
Notifications	Confirm which SMS, voice, push and chat channels are included for your plan.	SMS and voice only through Twilio, the sole supported provider. Slack and email are also supported.	SMS, phone call, push, email and Slack alerts are listed in the repository.
Alert sources	Confirm which Opsgenie integrations have Atlassian equivalents before cutover.	Generic API, email, Grafana, Prometheus, Site24x7 and Sensu are documented.	Monitors websites, APIs, ports, SSL, DNS and synthetic checks, plus OpenTelemetry agents.
Identity login	Uses Atlassian account and identity settings. Confirm SSO options with Atlassian.	GitHub OAuth and any OpenID Connect provider. Dex can bridge other identity systems.	SAML and OIDC single sign-on in Community Edition. SCIM provisioning is Enterprise only.
Hosting location	Atlassian-hosted service. Confirm which deployment and data location options apply to your contract.	Your own infrastructure. Needs a PostgreSQL database, recommended at version 17 or newer.	Your own infrastructure. Docker Compose on one Debian, Ubuntu or RHEL server, or a Helm chart for production.
License	Commercial subscription from Atlassian. Confirm terms and costs with Atlassian.	Apache 2.0, distributed as a single binary with Docker images.	Apache 2.0 Community Edition. The ee/ directory uses the OneUptime Enterprise License.
Main trade-off	Lowest change in tooling for Atlassian shops, but the commercial dependency remains.	You run the database, encryption key and high availability yourself, and Twilio is the only voice and SMS path.	Enterprise-only features include SCIM, audit logs, compliance dashboards, priority support and data residency. Confirm which you need before choosing.

How GoAlert and OneUptime fit into a self-hosted paging path

GoAlert runs as a single binary or a Docker image (goalert/goalert) with one hard dependency: a PostgreSQL database. The getting started guide recommends PostgreSQL 17 or newer for new installations and requires the pgcrypto extension, so the database version and extension are the first items to confirm in your environment. Set a data encryption key so that sensitive values such as API keys are encrypted before they reach the database, and use the same key on every instance, or stored secrets will not decrypt on the others. When you run several instances, for example in a Kubernetes cluster, designate one instance in the default engine mode and start the rest with the --api-only flag. The guide also states that database switchover is supported with minimal disruption, which matters if your paging system must stay up during a database maintenance window.

Alert ingestion is where most of the migration work lands. GoAlert accepts alerts through its generic API, through email (via Mailgun or a built-in SMTP ingress), and from Grafana, Prometheus, Site24x7 and Sensu. Map each Opsgenie integration to one of these sources before cutover, and list any Opsgenie integration with no matching source, since that gap needs a bridge or a change in the sending system. Notifications depend on Twilio, which is currently the only supported provider for SMS and voice in GoAlert, so the Twilio account, sender numbers and voice settings need their own test plan. Confirm the GitHub OAuth or OpenID Connect login setup as well, with Dex as the suggested bridge for identity systems that are not OIDC.

OneUptime is the other self-hosted path, and it covers more ground than paging alone. Its Community Edition is Apache 2.0 licensed, except the ee/ directory, and includes on-call schedules and escalation policies with SMS, phone, push, email and Slack alerts, along with incident management and status pages. Deployment is either Docker Compose on a single Debian, Ubuntu or RHEL server or the Helm chart the project recommends for production. Its OpenTelemetry-based agents also collect server, Kubernetes, Docker and database telemetry and run website, API, port, SSL, DNS and synthetic checks. Choose OneUptime when you want monitoring and paging in one system. Choose GoAlert when you need a narrower paging tool that sits behind existing monitoring. Either way, confirm the current release in the OneUptime releases page before you pin a version.

Deploying GoAlert or OneUptime and finishing the export before April 5, 2027

This sequence moves Opsgenie schedules, escalations and alert routing into a self-hosted GoAlert or OneUptime deployment before Opsgenie shuts down on April 5, 2027. Export comes first because unmigrated data is deleted at shutdown. The sequence ends with tested notifications and a cutover, with the export archive kept as a record.

Export schedules and timelines from Opsgenie
Start the export while Opsgenie is still active. Pull schedules as iCalendar files and incident timelines through the Schedule API, using the US or EU API host that matches your Opsgenie account and a GenieKey with read access. Confirm the host and authentication method in Atlassian's current export documentation before you run any script. Store the raw files in a restricted location, then record the count of schedules, rotations and timelines exported. Done means every schedule in the Opsgenie console has a matching file and you can open each one without errors.
Stand up PostgreSQL for the on-call platform
The platform team provisions a PostgreSQL database in your own cloud account or data center. GoAlert's getting started guide names PostgreSQL as its only hard requirement, recommends PostgreSQL 17 or newer for new installations, and requires the pgcrypto extension, so enable that extension before the first start. Configure backups and restore testing for this database from the outset, because it holds schedules, escalation policies and contact data. Done means the database accepts connections from the application hosts, the pgcrypto extension is installed, and a test restore has completed.
Deploy GoAlert or OneUptime in your environment
Deploy GoAlert as a single binary or from the goalert/goalert Docker image, using the release that matches your testing plan. The most recent release in the researched facts is v0.35.0, released September 21, 2026. For a multi-instance setup, run one instance in the default engine mode and the rest with the --api-only flag. If you need monitoring and status pages alongside on-call, OneUptime is the alternative to deploy, using Docker Compose on a single Debian, Ubuntu or RHEL server or the Helm chart the project recommends for production. Done means the web interface loads over your internal TLS endpoint and the health checks pass on every instance.
Set the shared encryption key and configure login
Generate one data encryption key and set it identically on every GoAlert instance, because the guide recommends it to protect sensitive values such as API keys before they reach the database. Store the key in your secrets manager and document who can read it, since losing it leaves encrypted values unusable. Then configure single sign-on with GitHub OAuth or any OpenID Connect provider. If your identity system is not directly supported, the guide suggests Dex as a bridge. Done means an administrator signs in through your identity provider and the key is confirmed identical across all instances.
Rebuild rotations, schedules and escalation policies
Recreate services, escalation policies, rotations and schedules in the new platform using the iCalendar exports and timelines as the reference. Add calendar subscriptions where teams already rely on them. Set up Twilio for SMS and voice, since the guide lists it as the only supported provider for those notifications, and add Slack channels as escalation steps where your teams use them. Compare each rebuilt schedule with the export, one team at a time. Done means every rotation and escalation path matches the Opsgenie source, and any Opsgenie feature without an equivalent is written down with an owner.
Re-point alert sources and test notifications
Inventory every Opsgenie integration and point each alert source at the new platform. GoAlert's documented sources include a generic API, email, Grafana, Prometheus, Site24x7 and Sensu. Where an Opsgenie integration has no equivalent, plan a replacement or accept the gap in writing. Test each path with a non-production service: SMS, voice, Slack, email, acknowledgement and escalation timeouts. Record the result of each test. Done means every alert source produces a page on the right schedule and each test result is logged.
Cut over and archive the export
Move alert sources in groups, starting with the lowest-risk services, and keep Opsgenie active until each group has been verified in production. Confirm with each on-call team that they receive pages from the new platform before disabling the old route. Keep the iCalendar files, timeline exports and configuration records in your retention store, because Opsgenie data is removed after shutdown. Done means no alert source still points at Opsgenie, the archive is verified, and the cutover is signed off by the service owners.

Questions buyers ask before choosing a replacement for Opsgenie

What drives the cost of GoAlert compared with Jira Service Management?

Jira Service Management is a recurring subscription paid to Atlassian, while GoAlert is free Apache 2.0 software whose costs are the infrastructure and services you run around it. The main recurring components are PostgreSQL hosting (GoAlert's only hard requirement, with PostgreSQL 17 or newer recommended for new installations), Twilio usage for SMS and voice notifications, and the compute for at least two instances if you want high availability. One-time costs include setup and testing. Ask any quote to split the Jira Service Management licensing from the GoAlert deployment, and to show which parts recur each year.

How do Twilio charges change the cost of self-hosted paging?

Twilio is the only supported provider for GoAlert voice and SMS notifications, so you pay Twilio directly for each message and call your on-call policies generate. Usage rises with the number of responders, the frequency of alerts and how many escalation steps reach a phone before someone acknowledges. Alerts sent only to Slack or email avoid those per-message charges but may not reach someone at 3 a.m. Before cutover, review last year's Opsgenie notification logs by channel and estimate volume with your own alert history, since no provider figure is supplied here.

How long does an Opsgenie to GoAlert migration take?

The duration depends on how many schedules, escalation policies, integrations and alert sources you have, and how many people must test notifications before you trust the new system. Teams with few schedules and simple escalations usually finish faster than organizations with many overlapping rotations and custom integrations. Opsgenie stops on April 5, 2027, and unmigrated data is deleted, so work backward from that date. Ask any implementation partner for a written timeline built on your inventory, and keep Opsgenie running in parallel until your test calls and alerts have been confirmed.

What must our team provide before a migration can start?

You need API access to Opsgenie with a GenieKey that can read teams, schedules, escalation policies and integrations, plus named owners for each schedule who can confirm rotations are current. You also need access to a PostgreSQL instance with the pgcrypto extension, a Twilio account if you use SMS or voice, and a DNS name and TLS certificate for the GoAlert endpoint. Finally, you need test windows where responders can receive simulated pages without disturbing live incidents. Reading the export documentation early helps you confirm what Opsgenie makes available to you.

Can our own engineers migrate from Opsgenie to GoAlert without outside help?

Yes, a capable platform team can deploy GoAlert from its single binary or Docker image, configure PostgreSQL and rebuild schedules, though the work is hands-on and must be tested carefully. The risk lies in gaps that appear only under real conditions: a missed override, a wrong time zone, an integration that still points at Opsgenie, or a notification path that was never tested. Set an internal owner, write a cutover checklist and run a test of every escalation policy before go-live. If your team lacks paging or on-call operations experience, that is usually the point where outside help is worth comparing.

When does a consultant or implementation partner help most?

A consultant is most useful when the migration has many schedules, regulated notification requirements, a need for high availability across instances, or a tight deadline before April 5, 2027. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing first. Ask for a written scope that covers export, rebuild, notification testing, cutover and documentation. A quote follows from that scope.

Should we choose OneUptime or GoAlert, and how do their versions affect planning?

GoAlert covers on-call scheduling, escalations and notifications, while OneUptime combines on-call with status pages, incident management and monitoring under an Apache 2.0 Community Edition with an enterprise ee/ directory. GoAlert v0.35.0, released September 21, 2026, is the release to plan against for GoAlert, and OneUptime 14.0.70, published October 18, 2026, is the version to plan against for OneUptime. Pin the exact versions you test and check release notes before every upgrade. Choose based on whether you need monitoring and status pages, or only paging, and confirm the features you rely on in each project's documentation.

What compliance evidence should we keep from an Opsgenie to GoAlert migration?

Keep a dated inventory of schedules, escalation policies and integrations, the export files, the mapping to GoAlert objects, and records of every notification test with its outcome. Document who approved each cutover step and how sensitive values such as API keys are protected, since GoAlert recommends a data encryption key shared by every instance. These records help your internal auditors or certification body assess the change. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or attestation.

Evidence to keep for an on-call change review

An on-call change touches who gets paged, how alerts reach them, and who can change the configuration. The records below show what changed, who approved it, and whether notifications worked before Opsgenie was switched off. DeployOpen prepares this evidence for your internal risk team or external auditor, but does not issue audit reports or attestations.

Exported schedule and escalation inventory

Keep a dated export of every Opsgenie schedule, rotation, escalation policy and alert source, taken before the April 5, 2027 shutdown. Pair it with the GoAlert equivalent, so each team and escalation step can be traced from the old system to the new one. Confirm that the export covers all teams, not only the default ones, and record any object you chose not to migrate and why.

Encryption key and access control configuration

GoAlert recommends a data encryption key so sensitive values such as API keys are encrypted before they reach the database, and the same key must be set on every instance. Record where the key is stored, who can read it, how it is rotated, and proof that every instance loads the same value. Auditors will also ask who holds database and administrative access to the GoAlert host.

Login provider settings

Capture the GitHub OAuth or OpenID Connect configuration used to sign into GoAlert, including the client registration, allowed users or groups, and any Dex bridge in front of another identity system. Export these settings and the list of accounts that can log in on the cutover date. This shows that access to paging controls follows your identity policy, not local shared accounts.

Notification test records

Store the results of test pages and calls for each escalation policy, covering SMS and voice through Twilio, Slack steps, and email-created alerts through Mailgun or the built-in SMTP ingress. Note the time, responder, channel and whether the acknowledgement came back. Testing is the strongest proof that an on-call change will page a human during an incident.

Cutover decision log

Write down each go or no-go decision, the date, the approver, the open issues at that point, and the rollback path if paging fails. Include the decision to run Opsgenie and GoAlert in parallel, if you did, and when Opsgenie alerts stopped. This log explains why the team moved when it did, which is what a risk review asks for first.

What changes for responders and administrators after cutover

Once GoAlert is live, responders receive pages through the channels you configure in the escalation policy, and the most important change is that the notification path is now yours to verify. GoAlert sends SMS and voice through Twilio, which its getting started guide describes as the only currently supported provider. Before cutover, confirm with Twilio and in your own environment that the countries where your responders live are covered for both SMS and voice, that sender numbers are registered where your carriers require it, and that a test page reaches every responder's phone. Schedules move from Opsgenie's rotation model into GoAlert's rotations and schedules, and calendar subscriptions let responders see their shifts in a personal calendar. Ask each responder to confirm their contact methods and time zone after import, because those values are the first thing that fails silently.

Administrators take on work that Atlassian previously handled. The database is the critical dependency: GoAlert needs PostgreSQL 17 or newer for new installations with the pgcrypto extension, so the backup schedule, restore test and point-in-time recovery must be defined by your team and checked against your own recovery objectives. Upgrades are yours to plan; check each release on the GoAlert releases page and test in a staging instance before production. The data encryption key must be identical on every instance, and losing it means losing access to stored API keys, so store it in your secrets manager with a documented recovery procedure. For identity, decide between GitHub OAuth, an OpenID Connect provider or Dex as a bridge to your directory, then confirm role assignments, since administrators and responders need different permissions. Finally, confirm that each alert source you re-pointed, including Prometheus, Grafana, email and the generic API, still reaches GoAlert after the cutover window closes.

Choosing the path for your team

This path suits teams whose incidents already become Jira issues and whose change, problem and service records live in Jira Service Management (JSM). Staying with Atlassian keeps those links inside one vendor's product, and Atlassian runs the hosting, so your team does not operate a paging database or notification accounts.

Existing Jira workflows: if alerts, incidents and follow-up work already move through Jira, JSM keeps that chain intact. Map each Opsgenie integration to its JSM equivalent before you decide.
Atlassian-managed hosting: Atlassian operates the service, so patching and uptime follow its terms. Ask for data location and support commitments in writing.
Recurring licensing: JSM is licensed by Atlassian, and the cost recurs on the user or agent tier you buy. Ask for a quote based on your user count and the tier that includes on-call scheduling and escalation.
Less platform work: there is no database, SMS provider account or upgrade cycle for your team to run, although schedules and escalation policies still need to be rebuilt.
Lowest engineering change: if data residency and vendor lock-in are not your drivers, this path needs the least new build work.

Before choosing this path, confirm with Atlassian which features your current Opsgenie setup depends on and whether JSM covers each one in your plan.

Official sources for the GoAlert and OneUptime migration

Start with the GoAlert getting started guide, which is the primary source for installation requirements. It states that PostgreSQL is the only hard requirement, recommends PostgreSQL 17 or newer for new installations and requires the pgcrypto extension. Read it before you provision a database, and confirm the encryption key approach it describes, since the same data encryption key must be set on every instance that shares the database. The GoAlert getting started guide also covers the single-instance and multi-instance layouts you will need for a highly available paging setup.

Pin your deployment to a specific release rather than tracking the default branch. The GoAlert GitHub releases page lists each version with its notes, and the project publishes a Docker image for every release under goalert/goalert. The latest release noted in our research is v0.35.0, released on September 21, 2026, so check the releases page for anything newer before you finalize your target version. Record the version you test with, because your cutover runbook and rollback plan should reference it.

For OneUptime, use the OneUptime GitHub repository to confirm which features sit in the Apache 2.0 Community Edition and which sit in the ee/ directory under the Enterprise License. Then check the OneUptime GitHub releases page for the release you plan to deploy. Our research recorded 14.0.70 as published on October 18, 2026, but confirm the current tag yourself. Ask your legal or procurement team to review the license split before you rely on any Enterprise-only capability for compliance evidence.

How DeployOpen deploys a self-hosted on-call replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Opsgenie end of support, that means scoping a self-hosted on-call replacement, building it in your environment, and handing over a working system your team can run.

How we scope

We confirm which Opsgenie teams, schedules, escalation policies and alert integrations must move before the shutdown.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
Scope names the chosen destination, whether GoAlert, OneUptime or Jira Service Management, and the notification providers in use.

How we build

We deploy GoAlert or OneUptime in your cloud account, data center or air-gapped network, with PostgreSQL as its database.
We configure the data encryption key, identity login and high availability settings so every instance shares the same secrets.
We rebuild rotations, escalation policies and alert sources, then test SMS, voice, Slack and email notifications before cutover.

How we hand over

We deliver documentation covering the configuration, runbooks for on-call scenarios and the export records taken from Opsgenie.
We walk your operations and on-call teams through schedules, escalations and how to respond to failed notifications.
We provide evidence of tested notifications and configuration so your own auditors can review the cutover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades for GoAlert or OneUptime releases and backups of the paging database.
We do not issue audit reports or certifications. Independent auditors and certification bodies perform those assessments.

Opsgenie end of support: self-hosted alternatives