Opsgenie vs OneUptime: which fits your on-call team
An Opsgenie renewal or the April 2027 end of support forces a decision about what replaces its on-call scheduling and alerting. OneUptime is a fit for teams that want on-call schedules, escalation policies, status pages, incident management and monitoring in one self-hosted product under the Apache 2.0 license for its Community Edition. Opsgenie is the better fit for teams already committed to Atlassian's destination, where on-call sits alongside Jira Service Management and the existing Atlassian workflows. Neither choice is wrong in itself. The question is which set of dependencies your team is prepared to own.
Start with the tooling you already run. If your public status page lives on Atlassian Statuspage, or your monitoring runs on Datadog, Zabbix or Prometheus, check how each candidate connects to those sources before you commit. OneUptime's Community Edition includes branded public and private status pages and monitors websites, APIs, ports, SSL and DNS, and it ingests telemetry through OpenTelemetry-based agents. Confirm which of your alert sources and integrations need native support and which would need custom webhooks or re-pointing. Also confirm which Enterprise Edition features, such as SCIM provisioning or audit logs, your identity and compliance requirements depend on, since those sit outside the Community Edition.
Two further factors usually settle the decision. The first is data residency: if alert payloads, incident records and customer-facing status data must stay in a specific country or your own data center, a self-hosted deployment meets that need, but data residency is listed as an Enterprise Edition feature, so ask the vendor how it applies to your deployment. The second is operating effort. OneUptime runs with Docker Compose on a single Debian, Ubuntu or RHEL server, or with a Helm chart that the project recommends for production. Someone on your team must own upgrades, backups, high availability and the notification channels for SMS, phone and push. Compare that ongoing work with the Atlassian path, and check the current OneUptime release notes before you plan an upgrade cycle.
When Opsgenie or OneUptime is the better fit
This table compares buyer scenarios and names which option fits better and the condition that decides it. Read each row against your own toolchain, data rules and team capacity, since the right answer often depends on one constraint rather than overall features. The main takeaway is that OneUptime fits teams that want on-call, status pages and monitoring in one self-hosted product, while Opsgenie fits teams already committed to Atlassian tooling and willing to confirm its end-of-support path.
| Buyer scenario | Better fit | Condition that makes it so |
|---|---|---|
| Atlassian-centered toolchain | Opsgenie or Jira Service Management path | Jira, Confluence and Bitbucket already drive your incident and change workflow, and you accept Atlassian's stated end-of-support path for Opsgenie. |
| Need to keep alert data in your own environment | OneUptime (self-hosted) | Your policy requires alert, incident and on-call data to stay in infrastructure you run, and you can host the Docker Compose or Helm deployment yourself. |
| Wanting one tool for status pages and monitoring | OneUptime | You want public and private status pages, uptime checks and incident communication in the same product as on-call schedules. |
| Small platform team without spare capacity | Opsgenie or a managed alternative | No one can own patching, backups, upgrades and high availability of a self-hosted paging system, so confirm the operating cost before choosing OneUptime. |
| Need for SCIM or audit logs | Confirm before choosing either | OneUptime Community Edition covers SAML and OIDC single sign-on, while SCIM provisioning and audit logs are in the Enterprise Edition, priced through sales. Ask Atlassian or OneUptime which controls you need in writing. |
| Existing PagerDuty or GoAlert plans | Stay with the existing tool, or compare GoAlert first | Your schedules and escalation policies already live in PagerDuty or GoAlert, so moving to OneUptime adds re-creation work without a new capability you need. |
| Heavy reliance on existing Opsgenie integrations | Opsgenie until cutover, then confirm the replacement | Your alert sources are many and tightly wired, so map each integration to a target before choosing a platform. |
What carries over from Opsgenie to OneUptime
Start by inventorying your Opsgenie configuration before you evaluate OneUptime in detail. The core on-call concepts map reasonably well: teams, schedules (rotations and overrides), escalation policies and the incident records that accumulate during an alert. OneUptime's documented feature set includes on-call schedules and escalation policies with alerts by SMS, phone call, push, email and Slack, and incident management from declaring and assigning an incident through communication, resolution and post-mortems. Export your Opsgenie teams, users, rotations and escalation chains, then list each one next to its OneUptime equivalent so you can see where the concepts line up and where your setup uses a construct that has no direct counterpart.
Plan to rebuild several areas by hand. Opsgenie's integrations, including the alert sources that send events to it, must be re-pointed to OneUptime's ingestion paths, and each source needs its own test. Custom routing rules, the logic that decides which team or escalation receives an alert based on tags, priority or payload fields, should be written down as explicit rules and re-created in OneUptime, then checked against sample alerts. Historical reporting is the area most likely to be lost: Opsgenie's past alert and response data will not automatically appear in OneUptime, so decide early which reports you need to keep and where that history will live, such as an archive export. Confirm each mapping against the OneUptime GitHub repository and the current release notes, since features and import tooling change between releases.
Do not plan around a one-click import. Treat the migration as a controlled rebuild: create a test team in OneUptime, recreate one schedule and one escalation policy, route a test alert from a non-critical source, and confirm the SMS, phone, push, email and Slack notifications your responders depend on actually arrive. Verify who is notified at each escalation step and what happens when a responder does not acknowledge. Only after those checks pass should you move production sources over. Ask the vendor or your implementation partner to confirm which Opsgenie objects have an import path, and record any items you must rebuild manually, so the cutover plan before Opsgenie's shutdown on April 5, 2027 reflects what is actually possible.
Opsgenie vs OneUptime feature by feature
This table maps the capabilities OneUptime Community Edition documents against the Opsgenie areas you need to confirm before migrating. The OneUptime column describes documented features, while the Opsgenie column lists what to verify in Atlassian's documentation and your own tenant. Use it to decide which Opsgenie workflows and data carry over and which need a replacement.
| Capability | OneUptime Community Edition | What to confirm for Opsgenie |
|---|---|---|
| Incident management | Declare and assign incidents, communicate progress, resolve, and write post-mortems in one workflow. | Map your current alert-to-incident steps, roles and post-mortem practice to OneUptime's flow before cutover. |
| On-call schedules and escalation | Schedules and escalation policies with alerts by SMS, phone call, push, email and Slack. | Export schedules and escalation rules, and confirm which notification channels and voice options your team uses today. |
| Status pages and subscribers | Branded public and private status pages with incident history, scheduled maintenance and subscriber notifications. | Confirm with Atlassian which product, if any, runs your status pages today, since it may not be Opsgenie. |
| Website, API, SSL, DNS and port checks | Monitors websites, APIs, IPs, ports, SSL, DNS and synthetic checks. | Confirm whether any of these checks run inside Opsgenie or in separate monitoring tools that send alerts to it. |
| Logs and telemetry ingestion | Ingests logs and telemetry through OpenTelemetry-based agents for servers, Kubernetes, Docker and databases. | Confirm which alert sources send events to Opsgenie today and re-point each one during migration. |
| Single sign-on and provisioning | SAML and OIDC single sign-on in Community Edition. SCIM provisioning is in Enterprise Edition. | Confirm SSO and SCIM support on your Opsgenie plan and how users are provisioned today. |
| Self-hosting and licensing | Apache 2.0 Community Edition, except the ee/ directory. Runs on Docker Compose or a Helm chart. | Opsgenie is an Atlassian-hosted service. Confirm your deployment options and the April 2027 end-of-support date with Atlassian. |
Community Edition or Enterprise Edition: what the license covers
OneUptime's Community Edition is licensed under the Apache License 2.0, with one exception: the ee/ directory in the repository uses the OneUptime Enterprise License. That split means the bulk of the code can be read, run and modified under a permissive license, while the code in ee/ carries its own terms. The Community Edition covers the core operational workflow that replaces much of Opsgenie's job, along with monitoring and status communication.
- On-call and escalation: Schedules, escalation policies and alerts by SMS, phone call, push, email and Slack.
- Incident management: Declaring and assigning incidents, communicating during them, resolving them and writing post-mortems.
- Status pages: Branded public and private status pages with incident history, scheduled maintenance and subscriber notifications.
- Monitoring and telemetry: Website, API, IP, port, SSL, DNS and synthetic checks, plus OpenTelemetry-based agents for servers, Kubernetes, Docker and databases.
- Single sign-on: SAML and OIDC support in the Community Edition.
Confirm with OneUptime and your legal team which parts of the repository you plan to deploy, especially if you modify code under ee/ or add it to a product you distribute.
The Enterprise Edition adds features aimed at identity administration, audit evidence, instance oversight and vendor support. These features sit under the OneUptime Enterprise License rather than the Apache 2.0 terms that cover the rest of the Community code. Pricing is handled through OneUptime sales, so you will not find a published price list to compare against Opsgenie or Jira Service Management.
- SCIM provisioning: Automated user lifecycle sync from your identity provider, which many teams require before they can drop manual account handling.
- Audit logs: Records of administrative and configuration activity that your security or compliance team may need as evidence.
- Compliance and instance health dashboards: Views intended to help operators track the platform itself, not only the services it monitors.
- Priority support: A support tier for production incidents affecting the paging system.
- Data residency: Controls over where data is stored, which matters for regulated organizations with location requirements.
Ask OneUptime sales for the written feature list, the support response terms and how data residency is implemented in your deployment model before you rely on any of these in an audit or procurement decision.
The practical distinction is between code you can inspect and self-host under Apache 2.0 and capabilities that depend on an Enterprise License agreement. Open-source availability tells you what you can run and audit. It does not guarantee that every feature a compliance team asks about is included in the free edition, and it does not replace a commercial support arrangement if your on-call process depends on fast vendor help.
- Code location: Community code outside
ee/is Apache 2.0, andee/is governed separately. - Feature gating: Identity provisioning, audit trails and residency controls are listed as Enterprise features.
- Support model: Community use relies on the project and your own operations team unless you buy a support tier.
- Upgrade path: Releases such as 14.0.70 may change either part of the repository, so review license headers when you upgrade.
- Documentation: Check whether any control you need is documented as Community or Enterprise before you plan around it.
Have legal counsel review the license terms against your intended use, including internal hosting, modification and any customer-facing status pages, before you commit to a design.
Where OneUptime runs and what that means for data control
OneUptime is self-hosted, so the choice of host, cluster and identity setup decides where incident, schedule and telemetry data lives. The cards below cover the deployment options the project documents, the data location questions to settle, and the evidence your organization must produce itself.
Single server with Docker Compose
OneUptime documents a Docker Compose deployment on a single Debian, Ubuntu or RHEL server. This suits a small pilot or a team that replaces Opsgenie for one service group. Confirm the host sizing, the storage volumes that hold incident history and logs, and who patches the operating system. A single host is also a single point of failure for paging, so decide early whether on-call alerts need a second path.
Helm chart for production
The project recommends a Helm chart for production deployments. It moves OneUptime onto a Kubernetes cluster that your platform team operates. Ask who owns the cluster, how persistent volumes and database backups are configured, and how upgrades are rolled out. For Opsgenie replacements, the cluster must be reachable by your alert sources and by the SMS, phone, push, email and Slack channels that carry alerts to responders.
Data stays in your environment
A self-hosted OneUptime keeps incident records, on-call schedules, status page history and ingested telemetry inside your cloud account or data center. Opsgenie data is hosted by Atlassian in regional sites, so this is a change of custodian. Map each data class to a location and to a retention rule, and confirm which outbound services (SMS, voice, Slack, email) receive personal contact details.
Single sign-on with SAML and OIDC
The Community Edition includes SAML and OIDC single sign-on, so responders can log in through your existing identity provider. Confirm which protocol your identity provider supports, how group membership maps to OneUptime roles, and how an account is disabled when someone leaves the on-call rota. SCIM provisioning is not in the Community Edition, so user lifecycle changes will need a manual or scripted process.
Enterprise residency and audit logs
The Enterprise Edition adds data residency, audit logs, SCIM provisioning, compliance and instance health dashboards, and priority support, priced through sales. If your regulator or internal policy requires documented access history for alert changes or schedule edits, audit logs are the feature to evaluate. Ask OneUptime for the written scope of each Enterprise feature before you plan around it.
Compliance evidence stays with you
Self-hosting does not give you a compliance report. DeployOpen can prepare controls, configurations and evidence for your assessment, but independent auditors and certification bodies issue any reports. Your organization must keep access reviews, backup test records, change logs for the paging configuration and incident post-mortems. Agree with your auditor in advance which of these artifacts they will accept.
What drives the cost of running OneUptime against Opsgenie
The cost comparison starts with who gets paid for what. Opsgenie is a subscription paid to Atlassian, so its licensing line is a single recurring number that changes with your plan and seat count. OneUptime Community Edition, licensed under Apache License 2.0, carries no license fee, but the cost does not disappear. You pay for the compute and storage that run the Docker Compose or Helm deployment, for backups and off-server copies, for the staff time that patches and upgrades it, and for the carrier charges behind SMS and voice paging. Each of these needs an owner on your side or in a DeployOpen engagement, and each should appear as its own line in your model.
Separate one-time work from recurring work. One-time costs cover the initial setup, rebuilding your on-call schedules and escalation policies in OneUptime, re-pointing alert sources, and testing notifications end to end before cutover. Recurring costs cover patching the platform, applying upgrades such as new releases, keeping the database and high availability design healthy, and paying for every page delivered. The main drivers are alert volume, which sets carrier charges and on-call fatigue, the number of monitors and telemetry sources, which sets storage and compute, retention periods for logs and incident history, and the number of responders on rotation. Confirm each driver against your current Opsgenie usage reports before you model the new platform.
For Enterprise Edition features such as SCIM provisioning, audit logs, compliance dashboards, priority support and data residency, request a written quote from OneUptime's sales team, since the project does not publish those prices. Ask the quote to state what is covered, the support response terms, and whether the license applies to the ee/ directory only. Ask your SMS and voice carriers for their own per-message and per-minute rates for each country where responders are located, because those rates, not the software, often decide the recurring total. Ask Atlassian for the current Opsgenie renewal price in writing as well, so both options are compared on identical scope and term.
How a move from Opsgenie to OneUptime works at a high level
The sequence moves schedules, escalation policies and alert sources out of Opsgenie, rebuilds them in a self-hosted OneUptime instance, and retires the old routing only after each notification channel has been tested.
Export schedules, escalation policies and alert sources
Before the April 5, 2027 shutdown, pull every on-call schedule, escalation policy, team, user contact method and integration from Opsgenie. The export method is covered on our separate export page, so use that as the reference for API hosts and authentication. Assign a named owner to each alert source, such as a monitoring tool, cloud alarm or application integration, so that every source has someone accountable for its re-pointing. The step is complete when you hold a written inventory of every schedule and integration, with an owner against each one and a copy stored outside Opsgenie.
Deploy OneUptime in your own environment
Install OneUptime in the infrastructure you control, using the Docker Compose path on a single supported Linux server or the Helm chart that the project recommends for production. Configure single sign-on through SAML or OIDC, set up backups, and confirm that the instance is reachable by the monitors and notification providers you plan to use. Your platform team owns this step, and DeployOpen can run it as part of a fixed-scope engagement. The step is complete when the instance passes an agreed health check and an administrator can log in through your identity provider.
Rebuild teams, schedules and escalation policies
Recreate each team, on-call rotation and escalation policy in OneUptime from the inventory you exported. Map Opsgenie's rotation logic, overrides and escalation timings onto OneUptime's schedules and escalation policies, and note any behavior that does not translate directly so the owner can decide on an equivalent. Check the result against the source schedules for the next several rotation periods. The step is complete when each schedule in OneUptime matches its Opsgenie source in a documented side-by-side review signed off by the team lead.
Re-point monitors and alert sources
Move each alert source to OneUptime, starting with the monitors that OneUptime can run natively, such as websites, APIs, ports, SSL and DNS checks, and then the OpenTelemetry-based agents for servers, Kubernetes, Docker and databases. For sources that still send to Opsgenie, change the integration endpoint or routing key in the source system, and keep the old Opsgenie integration disabled rather than deleted until cutover. Each source owner records the change. The step is complete when every source is either sending to OneUptime in staging or has a documented reason it cannot yet move.
Run parallel notifications and test each channel
Run Opsgenie and OneUptime side by side for a defined test window agreed by the owners. Send test alerts through every channel that the on-call engineers use, including SMS, phone call, push, email and Slack, and confirm that each one reaches the intended person and that acknowledgement and escalation behave as expected. Check that the notification providers you rely on for SMS and voice are configured under your own accounts. Record each test result. The step is complete when every channel has a passing test recorded for each escalation level.
Cut over and retire the old routing
Switch production alert sources to OneUptime, confirm that live incidents appear and route correctly, and then disable the Opsgenie integrations. Keep the exported archive and the Opsgenie data you need for audit purposes in storage you control before Opsgenie removes undeleted data. Confirm with your compliance lead which records must be retained and for how long. The step is complete when no live alert source routes to Opsgenie, the archive is verified, and the owners have signed off on the cutover record.
Opsgenie vs OneUptime: questions buyers ask before hiring help
Can a team self-host OneUptime alone without outside help?
Yes, a capable in-house team can self-host OneUptime, because the Community Edition is Apache 2.0 licensed (except the ee/ directory) and the project documents two self-hosting routes. The project describes Docker Compose on a single Debian, Ubuntu or RHEL server, and a Helm chart it recommends for production. The harder questions are operational: backups, upgrades, high availability for paging, notification provider accounts, and network reachability for monitored systems. Confirm these against the current OneUptime repository and decide early whether your team will own them after handover.
How long does an OneUptime migration take, and what sets the duration?
The duration depends on scope, not on a fixed figure, and no timeline is given here. The main drivers are how many Opsgenie schedules, escalation policies and integrations you run, how many alert sources must be re-pointed, how many status pages and monitors you need, and how much testing of notification paths your change process requires. Ask for a written, fixed scope with deliverables and dates before work starts, so the timeline follows from what is agreed.
What does the client's team need to provide during the engagement?
Expect to supply people who know your on-call rules and systems. That usually means an owner for the on-call policy, engineers who can confirm which alert sources feed which services, someone with access to your Opsgenie account and API exports, and an administrator for the target hosting environment. You will also need approvers for notification testing and cutover. Agree these roles and their time commitments in the written scope so delays do not come from unassigned decisions.
Do we need the OneUptime Enterprise Edition for our compliance goals?
It depends on which controls your assessor expects to see implemented in the tool itself. The Community Edition includes SAML and OIDC single sign-on. The Enterprise Edition adds SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency, and it is priced through sales. Map each control requirement to a feature before deciding, and ask OneUptime which edition provides each one. DeployOpen prepares systems and evidence for compliance assessments, but auditors and certification bodies issue the conclusions.
What happens to our Opsgenie history after April 5, 2027?
Opsgenie shuts down on April 5, 2027, and data that has not been migrated or otherwise retained is deleted. Schedules can be exported as iCalendar files, and timelines can be pulled through the Schedule API, using the US or EU API host with GenieKey authentication. Decide early which historical records you must keep for audit or incident review, and store them in your own environment. Confirm the export options for your account with Atlassian, because Data Center customers have a separate download option.
How do we confirm the current OneUptime release before planning?
Check the latest release yourself before you plan, because the most recent release you see may not be the one you deploy. At the time of writing, the researched release is OneUptime 14.0.70, published on October 18, 2026, according to the project's releases page. Review the OneUptime releases page for newer tags, read the changelog for breaking changes to Docker Compose or Helm configuration, and pin the version you test against. Ask DeployOpen to include a version confirmation step in the written scope.
What does DeployOpen do, and what do we keep in-house?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OneUptime, that covers the deployment, Opsgenie data handling, integrations, testing and documentation defined in the written scope. You keep ownership of your infrastructure, credentials, on-call policy decisions, and the final sign-off on cutover. Ongoing support and upgrades are available as retainers.
How DeployOpen helps evaluate, implement and migrate
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including OneUptime when it is the chosen destination for Opsgenie on-call work. Engagements start with a written, fixed scope so schedules, escalation policies and notification paths are agreed before any cutover begins.
How we scope
- Inventory Opsgenie teams, schedules, escalation policies and integrations before comparing them with OneUptime features.
- Agree in writing which on-call, status page and monitoring functions move, and which stay on another tool.
- Confirm the hosting target: a single Debian, Ubuntu or RHEL server with Docker Compose, or a Helm-based cluster.
How we build
- Deploy OneUptime in your own cloud account, data center or air-gapped network, with single sign-on configured.
- Rebuild on-call schedules and escalation policies, then wire alert sources and notification channels such as SMS, phone, push, email and Slack.
- Test every notification path end to end, including after-hours escalations, before any Opsgenie alert source is switched off.
How we hand over
- Document the configuration, schedules, escalation rules, integrations and the runbook for each on-call team.
- Hand over backup and restore procedures for the OneUptime database and configuration, with a tested restore.
- Record the decisions made on Enterprise Edition features such as SCIM, audit logs and data residency for your records.
How we support
- Support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
- Plan version upgrades against the OneUptime release notes before applying them to a production paging system.
- Ask for a quote built from the written scope. DeployOpen does not publish a price list.
