Open-source alternative to Datadog On-Call

Open-source alternative to Datadog On-Call for per-seat paging

If your renewal is a per-seat bill for Datadog On-Call, the decision you need to make is whether paging alone justifies the seat cost. GoAlert covers on-call scheduling, automated escalations and SMS or voice notifications as a single binary backed by PostgreSQL, while OneUptime pairs on-call schedules and escalation policies with status pages and incident management. Datadog's pricing list shows On-Call at $20 per seat per month billed annually, $24 month-to-month or $29 on demand, according to Datadog's pricing list. That seat price is only one module of a larger platform, so count which other Datadog products your responders actually open during an incident before comparing totals.

Seat cost is the recurring part, but the self-hosted side has its own components. GoAlert needs a PostgreSQL database (the getting started guide recommends PostgreSQL 17 or newer for new installations, with the pgcrypto extension), a server or Kubernetes cluster to run the binary, and an encryption key for sensitive values such as API keys, which must be identical on every instance. Notifications are the cost to confirm first: GoAlert's getting started guide names Twilio as the only supported provider for SMS and voice, so ask your telephony team what per-message and per-minute rates would apply to your expected paging volume, and who in your organization owns that account. Staff time to maintain the database, upgrades and the Twilio integration is the remaining recurring cost.

Before you move, check two things against your own environment. First, confirm which alert sources you need to route into the new tool: GoAlert accepts alerts from a generic API, email, Grafana, Prometheus, Site24x7 and Sensu, so Alertmanager or Grafana alert rules can be connected without changing how services are instrumented. Second, if you rely on OneUptime's status pages or its on-call alerts through push, phone, email or Slack, confirm that the Community Edition provides the notification paths and single sign-on your identity provider requires, since some enterprise features such as SCIM provisioning and audit logs are only in its Enterprise Edition. Ask any implementation partner for the migration plan in writing, including how existing rotations and escalation policies will be recreated and tested before Datadog On-Call is disabled.

Which open-source tool covers each Datadog On-Call capability

This table maps each Datadog On-Call capability to GoAlert, OneUptime, or a gap that needs confirmation. Read a check as documented in the supplied sources, a cross as not documented in those sources, and a dash as not applicable; the main takeaway is that GoAlert covers on-call routing closely, while OneUptime adds status pages and incident management but needs its routing details confirmed.

Capability	GoAlert	OneUptime
On-call schedules and rotations	Rotations, schedules and calendar subscriptions are documented	On-call schedules are included in Community Edition
Escalation policies	Escalation policies with automated steps are documented	Escalation policies are included; confirm step and timeout options in its docs
Notification channels	SMS and voice through Twilio only; Slack channel steps are supported	SMS, phone call, push, email and Slack are listed; confirm provider details
Alert ingestion	Generic API, email, Grafana, Prometheus, Site24x7 and Sensu sources	OpenTelemetry-based agents ingest telemetry; confirm Alertmanager routing
Status pages	Not a documented capability	Branded public and private status pages with subscriber notifications
Incident management	Not a documented capability; pair with a ticketing or ITSM tool	Covers declaring, assigning, communicating, resolving and post-mortems
Single sign-on	GitHub OAuth and any OpenID Connect provider; Dex bridges other systems	SAML and OIDC in Community Edition; SCIM needs Enterprise Edition
Self-hosting footprint	Single binary plus PostgreSQL 17 or newer with pgcrypto	Docker Compose on one server or a Helm chart for production
Licensing	Apache 2.0	Apache 2.0 for Community Edition; ee/ directory under enterprise license

Choosing between GoAlert and OneUptime

GoAlert and OneUptime both replace the paging side of Datadog On-Call, but they differ in scope. The cards below set out where each fits, what each asks of your team, and which edition features to confirm before you commit.

GoAlert for focused paging

GoAlert covers on-call schedules, escalation policies, rotations and notifications, and it does not try to be a monitoring product. It is Apache 2.0 and ships as a single binary, so the footprint stays small. Alerts can arrive from Prometheus, Grafana, email or a generic API, which suits teams whose metrics already live in Alertmanager or Grafana. Check that the notification providers you need are supported, because Twilio is the only supported provider for SMS and voice today.

OneUptime for an integrated stack

OneUptime bundles on-call schedules, escalation policies and incident management with uptime monitoring, status pages and OpenTelemetry-based log ingestion. This fits teams that want paging, public status communication and monitoring under one login and one upgrade path. The trade-off is scope: you run more components, and you must decide whether the monitoring features replace tools you already operate or sit alongside them.

Database and deployment requirements

GoAlert needs PostgreSQL as its only hard requirement, with PostgreSQL 17 or newer recommended for new installations and the pgcrypto extension enabled. Set a data encryption key that is identical on every instance, because it protects API keys stored in the database. OneUptime runs with Docker Compose on a single Debian, Ubuntu or RHEL server, or with the Helm chart the project recommends for production. Confirm which database and cluster standards your platform team already supports before choosing.

Community Edition and Enterprise boundaries

OneUptime's Community Edition is Apache 2.0 outside the ee/ directory, which carries the OneUptime Enterprise License. Community Edition includes SAML and OIDC single sign-on. SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency belong to the Enterprise Edition, which is priced through sales. If an auditor will ask for audit logs or automated user provisioning, get the Enterprise scope in writing before you plan around it.

Identity and login options

GoAlert supports GitHub OAuth and any OpenID Connect provider for login, and it suggests Dex to bridge other identity systems. OneUptime supports SAML and OIDC in Community Edition. Map each on-call responder to the identity source that already controls their access, and test how a departed engineer loses access to paging, since removing someone from the directory must also remove them from escalation rotations.

Migration and parallel paging

Whichever tool you choose, route a copy of alerts to it while Datadog On-Call still pages, and compare acknowledgement and escalation behavior for a few on-call cycles. Export schedules and escalation rules from Datadog as a reference, then rebuild them rather than copying settings across. Confirm that your notification path, including phone numbers and Slack channels, works end to end before switching primary routing.

Keeping Datadog monitors while paging moves

This situation keeps every Datadog monitor where it is and sends its notifications into the new paging tool. Datadog monitors keep their thresholds, query history and dashboards, so the change is limited to the notification path. The new tool receives an alert through a webhook or email and then applies its own schedules and escalation policies. This is the fastest way to stop paying for Datadog On-Call, but it keeps you on Datadog for detection.

Notification channel: Datadog can send monitor notifications to a webhook or email address, and the receiving tool must accept that payload format.
Alert deduplication: Datadog re-notifies on a repeat cadence, so confirm whether the receiving tool groups repeated alerts into one incident.
Resolution events: Confirm that recovery messages reach the new tool, or incidents will stay open after the problem is gone.
Ownership mapping: Map each Datadog monitor tag or team to a schedule in the new tool before cutover.
Dependency on Datadog: Detection and billing for monitors still depend on the Datadog contract.

Before you commit, confirm with Datadog whether webhook and email notifications are included in your plan and which payload fields a test monitor sends.

Moving schedules, escalations and users off Datadog On-Call

This sequence moves on-call schedules, escalation policies and responder identities from Datadog On-Call to a self-hosted paging tool, with a dual-paging window that proves the new routes before Datadog is switched off.

Document teams, schedules and escalation policies
The team lead or on-call owner records every team, rotation, schedule layer, override and escalation policy in Datadog On-Call, including who is paged at each step and how long each step waits before escalating. Start with what the Datadog admin console and API expose for your account, because the export options for on-call configuration vary, so confirm them in your environment before relying on an automated export. The step is done when a written inventory exists that another engineer could use to rebuild every route without asking the original author.
Deploy GoAlert or OneUptime with PostgreSQL
The platform engineering team installs the chosen tool in your own infrastructure. GoAlert is distributed as a single binary and Docker images under goalert/goalert, and its only hard requirement is PostgreSQL, where the getting started guide recommends PostgreSQL 17 or newer and requires the pgcrypto extension. OneUptime self-hosts with Docker Compose on a single Debian, Ubuntu or RHEL server, or with the Helm chart the project recommends for production. The step is done when the service answers on its internal address and a test user can log in.
Set the data encryption key across all instances
The security engineer generates one data encryption key for GoAlert, which the getting started guide recommends to encrypt sensitive values such as API keys before they are written to the database. Store it in your secrets manager and inject the same key into every instance, because instances with different keys cannot read each other's data. In a multi-instance deployment, such as a Kubernetes cluster, run one instance in default engine mode and the rest with the --api-only flag. The step is done when every instance starts, reads the same configured data and reports the same schedules.
Connect identity through OIDC or GitHub OAuth
The identity team registers the new tool with your identity provider. GoAlert supports GitHub OAuth and any OpenID Connect provider for login, and suggests Dex to bridge identity systems that are not OIDC-compatible. OneUptime's Community Edition provides SAML and OIDC single sign-on, while SCIM provisioning is listed under its Enterprise Edition, so confirm the provisioning model you need before you rely on automatic user removal. The step is done when responders sign in with corporate accounts and each person maps to the correct schedule and contact methods.
Repoint alert sources and notification channels
The monitoring owner changes the routing of each alert source from Datadog to the new tool. For Prometheus Alertmanager, that means updating receiver configuration to point at the new integration endpoint. For Grafana alerts, it means changing the contact point. GoAlert accepts alerts from a generic API, email, Grafana, Prometheus, Site24x7 and Sensu. Confirm the notification provider before cutover: Twilio is currently the only supported provider for GoAlert voice and SMS, so check that your SMS and phone routes meet your carrier and country needs. The step is done when a test alert from each source creates an incident in the new tool.
Run a dual-paging test window
The on-call lead keeps Datadog On-Call active while the new tool receives the same alerts, so each alert pages through both systems. Use the window to check that every responder receives SMS, voice, push or email as expected, that escalations fire at the right step, that overrides and handoffs match the written inventory, and that acknowledgements in one tool close the matching incident in the other where that is intended. Record each gap and its fix. The step is done when a test scenario for every escalation policy has produced the expected pages with no missed responders.
Cut over and retire the Datadog routes
After the test window passes, the on-call lead removes Datadog On-Call as a receiver in every alert source and announces the new paging path to responders. Keep the Datadog configuration in read-only form and retain a copy of the exported inventory for audit and rollback reference until your retention policy allows deletion. Cancel or change the Datadog On-Call seats according to your contract terms, which your Datadog account team can confirm. The step is done when no alert source sends to Datadog On-Call and the first live incident is handled end to end in the new tool.

What Datadog On-Call costs versus self-hosted paging

The main recurring line in Datadog On-Call is seat pricing. Datadog's pricing list shows On-Call at $20 per seat per month billed annually, $24 month-to-month or $29 on demand, so a responder roster is priced by headcount and by the billing term you choose. Moving to a self-hosted tool replaces that line with infrastructure and labor, and the switch is only cheaper if those components are sized honestly. Ask your Datadog account team to confirm the seat count and billing term on your current invoice, because on-call rosters often include people who are rarely paged and can be removed from the paid count before you start comparing.

On the self-hosted side, the recurring costs are the server or container hosting for GoAlert or OneUptime, the PostgreSQL database that GoAlert requires, and Twilio usage for SMS and voice notifications, since Twilio is the only supported provider for GoAlert voice and SMS. Telephony usually grows with the number of pages and the number of responders per escalation step, so it rises with incident volume rather than headcount. Staff time for upgrades, database backups, certificate renewal and single sign-on configuration with GitHub OAuth or an OpenID Connect provider is the cost most often left out. One-time costs include the migration of schedules and escalation policies, the alert source rewiring described elsewhere on this page, and the initial hardening and testing. A partner quote should separate these lines, state who performs each task, and list what is fixed-scope versus retained for ongoing support. DeployOpen provides quotes from a written scope rather than a published price list.

Questions buyers ask before replacing Datadog On-Call

What does replacing Datadog On-Call cost, and what drives it?

Datadog On-Call is priced per seat, and the Datadog pricing list shows $20 per seat per month billed annually, $24 month-to-month or $29 on demand. Self-hosted GoAlert or OneUptime removes the per-seat fee, so your cost moves to the parts you run yourself: a PostgreSQL database, a small server or Kubernetes capacity, an SMS and voice provider account, backups, and the people who maintain the system. Seat count, notification volume and how many instances you run for high availability are the main drivers. Ask any implementation partner for a written quote that separates one-time setup from recurring infrastructure and support.

How long does an on-call migration take?

Duration depends mainly on the number of schedules, escalation policies and alert sources you move, and on how many integrations must be rebuilt. A team with a few rotations that alert only from Prometheus or Grafana is a much smaller job than one with dozens of schedules, Slack escalation steps, email-based alert intake and custom API senders. Because the work is usually fixed-scope, DeployOpen agrees the timeline in writing before work starts, after reviewing your current schedules and routing. Ask for the timeline to be tied to named deliverables, such as cutover of each alert source.

What must our team provide before migration starts?

Plan to supply an export or list of your current services, schedules, rotations, escalation policies and notification rules, plus the alert sources that page them. You will also need access to the target hosting environment, a PostgreSQL database that meets GoAlert's requirements, identity provider details for login, and a named owner who can approve routing changes. For a GoAlert build you will need a Twilio account if you want SMS or voice, and for OneUptime you will need the sending channels you intend to use. Confirm each dependency in the written scope so that nothing blocks the cutover window.

Can our own engineers run the migration without a partner?

Yes, a team with Kubernetes or Linux operations experience can deploy GoAlert, which is distributed as a single binary with Docker images, or OneUptime, which runs with Docker Compose or a Helm chart. The harder part is usually not installation but re-creating schedules, escalation logic and alert routing without gaps, then testing failover and notifications under real conditions. Plan for named staff to own the system after go-live, including upgrades and database backups. If that staffing is thin, a fixed-scope engagement or a retainer for ongoing support can cover the gap.

Does GoAlert's Twilio-only notification support matter for us?

It matters if your notification design depends on a provider other than Twilio. The GoAlert getting started guide states that Twilio is currently the only supported provider for voice and SMS notifications. If your contracts, country coverage or carrier rules require another provider, you need to confirm that before choosing GoAlert, or plan a different delivery path. GoAlert can also notify Slack channels as an escalation step and create alerts from email through Mailgun or its built-in SMTP ingress, which may cover some needs. Verify Twilio pricing and country coverage directly with Twilio for your region.

Does OneUptime Community Edition meet our single sign-on needs?

OneUptime Community Edition includes SAML and OIDC single sign-on, according to the project's repository. That covers many identity providers, but you should still test your specific IdP configuration, group mapping and session behavior in a staging instance before relying on it. SCIM user provisioning is not in the Community Edition, so user onboarding and removal will be manual unless you build automation. Confirm these points against the current release notes before you commit to a design.

How do we confirm which Enterprise features we need?

Start by listing the controls your auditors and security team expect, such as SCIM provisioning, audit logs, instance health dashboards, data residency and priority support. OneUptime's repository states that the Enterprise Edition adds SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency, priced through sales. Ask OneUptime for a written feature comparison and pricing for your required scope, and confirm the license terms for the ee/ directory before deployment. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any reports or certifications.

Risks to plan for before cutover

Moving paging from Datadog On-Call to a self-hosted tool changes who sends the notification, where the data lives and who answers when the new system fails. The risks below connect because each one can cause a page to be missed during the switch, so plan the mitigations before any schedule moves.

Missed pages during cutover

During the switch, some alerts may still route to Datadog while others route to GoAlert or OneUptime, or a rotation may exist in one tool but not the other. Run both paths in parallel for a defined period and send a test page through every escalation policy, including the final step. Confirm that each service in the new tool has a responder, and keep Datadog On-Call active until a full on-call rotation has passed without a missed acknowledgement.

Notification provider dependency

GoAlert documents Twilio as the only supported provider for voice and SMS notifications. If your current setup relies on a different carrier arrangement, or your Twilio account is in a region or contract that your security team has not approved, SMS and phone escalation may not work. Confirm the provider, the sender numbers, the account owner and the fallback for each responder's country before you rely on the new tool for night-time paging.

PostgreSQL availability and backups

GoAlert's only hard requirement is a PostgreSQL database, and it recommends PostgreSQL 17 or newer for new installations with the pgcrypto extension. The paging system is only as available as this database, so it needs high availability, tested point-in-time backups and a restore drill that includes the schedule and escalation tables. Ask your database team who owns it and how a failover is handled during an active incident.

Encryption key handling across instances

GoAlert recommends a data encryption key so that sensitive values such as API keys are encrypted before they are written to the database, and every instance must use the same key. If the key is lost, stored credentials cannot be read, and a mismatched key across a Kubernetes deployment causes failures that are hard to diagnose. Store the key in your secrets manager, define rotation procedures in advance and document who can read it.

Identity provider gaps

GoAlert supports GitHub OAuth and any OpenID Connect provider for login, and suggests Dex to bridge other identity systems. If your workforce identity runs on SAML or an directory service that Dex does not bridge cleanly, responders may be unable to sign in during an incident. Test login with every group that holds a schedule, confirm how account deprovisioning works when someone leaves the rotation, and keep a break-glass admin account with documented access.

Unclear coverage of integrations

Your monitoring tools send alerts to Datadog On-Call through integrations that may not exist in the new tool in the same form. GoAlert lists alert sources including a generic API, email, Grafana, Prometheus, Site24x7 and Sensu, and Prometheus Alertmanager or Grafana alerts can be routed into it. Inventory every alert source and every Slack or Jira destination, then confirm each one is covered by a documented route or a custom integration before cutover.

How DeployOpen scopes and delivers an on-call replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so an on-call replacement for Datadog On-Call runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory current Datadog On-Call schedules, escalation policies, users and notification channels before anything is built.
Confirm which alert sources feed paging, such as Prometheus Alertmanager, Grafana alerts or Datadog monitors, and where each one routes.
Agree in writing which notification providers, identity login method and PostgreSQL hosting the on-call tool will use.

How we build

Deploy the chosen on-call platform, GoAlert or OneUptime, in your environment with the data encryption key and database settings documented.
Wire Alertmanager or Grafana alert routing into the new tool and test each escalation path with scheduled drills.
Set up single sign-on, notification providers and access controls, then test them against your security requirements.

How we hand over

Deliver runbooks covering schedule changes, escalation edits, notification provider rotation and recovery steps.
Document the architecture, configuration, backup and upgrade procedures so your own engineers can operate the tool.
Run a cutover checklist that confirms every Datadog On-Call schedule has a working counterpart before access is removed.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Review each new release of the on-call platform and plan upgrades in your maintenance windows.
Ask for a written quote that lists components, support hours and testing scope before committing to a retainer.

Open-source alternative to Datadog On-Call