Which fits your on-call needs: PagerDuty or self-hosted GoAlert
If your renewal, a per-user price change or a data residency requirement has you reviewing PagerDuty, the question is whether your team needs more than on-call scheduling and escalation. If it mainly needs rotations, escalation policies and SMS or voice paging, self-hosted GoAlert covers that core and runs inside your own infrastructure. If you rely on PagerDuty's wider incident platform, moving the paging core alone will leave gaps you must fill with other tools. PagerDuty fits teams that want one vendor for on-call, incident coordination, AIOps, status pages and post-incident work, and that are willing to pay per user and for platform add-ons to get it. GoAlert, which is licensed under Apache 2.0 and distributed as a single binary, fits teams that want to own the paging path, keep alert routing and contact data on their own servers, and accept that AIOps, status pages, runbook automation and post-incident tooling are outside its scope. Its alert sources include a generic API, email, Grafana, Prometheus, Site24x7 and Sensu, so the monitoring you already run can usually feed it directly. The decision turns on three checks. First, list which PagerDuty features your responders use each week, especially AIOps, status pages, runbook automation and post-incident reviews, and whether any of them must be replaced before you can switch. Second, confirm you can operate PostgreSQL with the pgcrypto extension, since it is GoAlert's only hard requirement, and that you can keep the data encryption key identical on every instance. Third, confirm you have a Twilio account, because Twilio is currently the only supported provider for GoAlert voice and SMS, and that its message and call charges fit your alert volume.
Capabilities compared: PagerDuty and GoAlert
This table compares the on-call and paging capabilities of PagerDuty with self-hosted GoAlert, plus the adjacent features GoAlert does not cover. Where a PagerDuty feature is not covered by the supplied facts, the cell tells you what to confirm against your own contract and documentation. Use it to decide which capabilities you must replace and which you will keep elsewhere.
| Capability | PagerDuty | Self-hosted GoAlert |
|---|---|---|
| On-call schedules and rotations | Hosted schedules and rotations; confirm current features and limits in PagerDuty documentation | Schedules, rotations and calendar subscriptions are documented in GoAlert |
| Escalation policies | Hosted escalation policies; confirm multi-level and timing options against your plan | Automated escalation policies are a core GoAlert function |
| SMS and voice notifications | Provider handled by PagerDuty; confirm supported countries and channels | Twilio is the only supported provider for SMS and voice; you hold the Twilio account |
| Slack and email alert sources | Native integrations; confirm the list for your plan | Slack channels can be an escalation step; email alerts via Mailgun or built-in SMTP ingress |
| Prometheus and Grafana integration | Supported through PagerDuty integrations; confirm the exact setup | Alert sources include Prometheus and Grafana, plus a generic API |
| Login options | Confirm SSO and SAML options for your plan | GitHub OAuth and any OpenID Connect provider; Dex can bridge other identity systems |
| AIOps and event intelligence | Available on some PagerDuty plans; confirm scope before comparing | Not covered by GoAlert; plan a separate tool or manual triage |
| Status pages | Offered as an add-on or with platform plans; confirm terms | Not covered by GoAlert; see the status page alternative for self-hosted options |
| Runbook automation and post-incident tooling | Confirm available automation and retrospective features with PagerDuty | Not covered by GoAlert; plan a separate runbook and post-incident tool |
Where on-call data and notifications are processed
PagerDuty runs as a vendor-hosted service, and your services, schedules, escalation policies, users and incident history sit in the regional account you create. The vendor operates the database, the application tier and the notification delivery, so your team's control is limited to account configuration, access roles and the data you export. Data residency is set by the region chosen when the account is created, which is why moving regions later is a migration rather than a settings change.
- Data custody: The vendor holds the incident and user records in the account's region, and you rely on its contractual and technical controls.
- Key management: Encryption keys for stored data are managed by the vendor, not by your team.
- Notification path: SMS, voice and push deliveries are handled by PagerDuty's own delivery infrastructure, and you cannot inspect that path directly.
- Evidence: Request the current security and compliance reports, the list of subprocessors and the regional hosting statement from the vendor, and confirm which certifications cover your account's region.
- Change control: Access logs and audit records are available inside the product, so confirm their retention period and export options before you depend on them.
Confirm all PagerDuty regional hosting details, certifications and subprocessor lists directly with the vendor, because they change and apply to specific account types.
With GoAlert, your team runs the paging application as a single binary or Docker image inside your own cloud account, data center or air-gapped network. The application requires a PostgreSQL database, which you choose, host and back up, and the notification provider is configured by you. Your organization therefore decides where on-call data is stored, who can reach the database and how notifications leave your network.
- Database ownership: Your team or your platform provider holds the PostgreSQL instance, including its backups, replicas and retention. The getting started guide requires the pgcrypto extension and recommends PostgreSQL 17 or newer for new installations.
- Encryption key: GoAlert recommends a data encryption key so that sensitive values such as API keys are encrypted before they are written to the database. The same key must be present on every instance, so store it in your secrets manager and document its rotation.
- Twilio processing: Twilio is currently the only supported provider for voice and SMS, so message and call content and phone numbers pass through Twilio's infrastructure under your Twilio account terms.
- Identity and audit: Login can use GitHub OAuth or an OpenID Connect provider, with Dex suggested to bridge other identity systems. Your identity provider logs and GoAlert's own records become the access evidence you collect.
Confirm your database location, backup encryption, key custody and the Twilio region and data handling terms against your own architecture before you draw the data flow.
Notifications are where on-call data leaves a paging system, so the provider path matters as much as where the database sits. With PagerDuty, the vendor's delivery network sends messages and calls. With GoAlert, Twilio is the single supported voice and SMS provider, while Slack steps and email ingress through Mailgun or built-in SMTP add other paths you must document.
- Voice and SMS: Each page sends phone numbers and message text to Twilio, which then routes them to carriers.
- Slack steps: A Slack escalation step sends alert text to the channel you configure, so restrict channel membership accordingly.
- Email ingress: Alerts created from email pass through Mailgun or your SMTP ingress, which you must secure and log.
- Provider accounts: Twilio and Mailgun accounts, their API keys and sub-accounts are your responsibility, and the keys belong in your secrets store.
- Cost drivers: Message and call volume, number of countries reached and retries all change the Twilio bill, so ask for those figures in any quote.
Confirm with Twilio where messages and calls are processed for your numbers and whether your contract covers the data classes you send.
A compliance assessment asks how access is granted, how changes are recorded and where data is held, and the answers differ by model. A hosted PagerDuty account gives you vendor reports to request. A self-hosted GoAlert gives you configuration you control and logs you must keep. DeployOpen prepares systems, controls and evidence for an assessment, but independent auditors and certification bodies issue any audit report or certification.
- Access control: Document who holds administrative roles in GoAlert, how the GitHub or OpenID Connect login is enforced and how service accounts are limited.
- Change records: Keep version control for the deployment, the release version you run and configuration changes, including the encryption key rotation log.
- Data flow diagram: Show the database, the application, the identity provider and each notification provider, with the location of each.
- Backup and restore: Record backup schedules, encryption of backups and tested restore results for the PostgreSQL database.
- Vendor evidence: For each provider, file the contract terms and data processing documents that cover Twilio, Mailgun and any hosted PagerDuty account.
Confirm the specific controls and evidence your assessor expects with your auditor before you finalize the evidence set.
What Apache 2.0 licensing means for GoAlert
GoAlert is licensed under Apache 2.0, so the software itself carries no per-user or per-seat subscription from the project. It ships as a single binary, and Docker images are published for each release as goalert/goalert. The cost model changes: you pay for the infrastructure that runs it, the PostgreSQL database it depends on, and the Twilio account that delivers SMS and voice calls, and your team takes on the work that a SaaS vendor would otherwise handle. That work includes applying each release, hardening the host and container, managing the data encryption key and rotating credentials, and keeping backups and database switchover tested.
PagerDuty is sold per user and under platform plans, and the price you pay depends on the seats, add-ons and terms in your own agreement. Before you compare, read your current contract and order form, confirm which user roles and features you pay for, and note the renewal date and any notice period. Ask your account team to state in writing which paid add-ons are required to match the on-call scheduling, escalation and paging functions you use today, so the comparison covers the same scope on both sides.
Apache 2.0 also means your team can modify the code, but any change you make becomes a maintenance item for every future upgrade. Decide who owns patch intake, who reviews release notes before each upgrade, and who is on call for the paging system itself, since GoAlert is the component that wakes people when other systems fail.
What GoAlert leaves out and how teams cover it
GoAlert covers the paging core: schedules, escalations and notifications. The gaps below are where PagerDuty customers often rely on other features, so confirm each one against your current PagerDuty usage before you cut over. Each card names the condition under which the gap matters and the workaround to validate in your own environment.
AIOps and event intelligence
PagerDuty's event intelligence groups, deduplicates and suppresses alerts before they page anyone. GoAlert does not provide equivalent correlation, so every alert from a noisy source reaches an engineer as configured. This matters most if you route high volumes from Prometheus or Grafana. Confirm whether your alert rules already deduplicate upstream, and consider grouping and inhibition in Prometheus Alertmanager before events reach GoAlert.
Status pages
PagerDuty status pages are sold as an add-on or with platform plans. GoAlert does not publish customer-facing status pages, so incident communication to customers needs a separate tool. If your customers depend on public status updates, plan a self-hosted status page and link it to your incident process. A dedicated page covers this option in more detail.
Runbook automation
PagerDuty's automation actions can trigger scripts or workflows from an incident. GoAlert pages people but does not run remediation steps for them. If your responders depend on one-click diagnostics or restarts, inventory those actions and rebuild them with your existing automation tooling, such as Rundeck or Ansible jobs, and link the runbook from each service in GoAlert.
Post-incident tooling
PagerDuty's post-incident workflows collect timelines, responders and follow-up reviews in one place. GoAlert records alerts and notifications but does not manage the review process. Decide where incident timelines will live, such as a wiki, a ticketing system or a document template, and confirm that someone owns exporting the GoAlert alert history for each review.
Mobile app features
PagerDuty's mobile app supports acknowledgement, incident detail and override actions from a phone. GoAlert's notifications rely on SMS and voice paths, and you should confirm what the reader's device flow supports, including acknowledgement by reply or link. Test acknowledgement from the phone types your on-call staff actually use before retiring PagerDuty.
Vendor-run uptime and support
PagerDuty operates the paging service, its availability and its support desk. With GoAlert, your team runs the binary, the PostgreSQL database and the Twilio connection, so availability depends on your high availability design and on-call for the paging system itself. Ask who will respond when the paging path fails, how database switchover is rehearsed and whether a backup paging channel exists for outages.
How a move from PagerDuty to GoAlert runs
The sequence moves paging from PagerDuty to a self-hosted GoAlert instance in an order that keeps a working notification path at every stage, so cutover happens only after parallel paging tests pass.
Deploy GoAlert on PostgreSQL 17 or newer
Your platform or infrastructure team stands up PostgreSQL 17 or a newer release with the pgcrypto extension enabled, then runs GoAlert from its single binary or the goalert/goalert Docker image. Set one data encryption key and use the same key on every instance, since GoAlert uses it to encrypt sensitive values such as API keys before they are written to the database. For more than one instance, run one in default engine mode and the rest with --api-only. Done means the instance starts, the admin login works through your chosen identity provider, and the database backup job covers the GoAlert schema.
Configure Twilio for voice and SMS
Your telephony owner creates a Twilio account, provisions a sending number, and enters the credentials into GoAlert, since Twilio is currently the only supported provider for GoAlert voice and SMS notifications. Test each responder's phone number with a test notification and confirm delivery on both SMS and voice. Confirm the Twilio account owner, billing contact and number ownership now, because these outlive the migration. Done means every test user receives an SMS and a voice call from the production number.
Export services, schedules and escalation policies
An engineer pulls services, escalation policies, schedules, users and their contact methods from PagerDuty through its REST API, using the US or EU host that matches your account. Store the exports in version control or an approved repository, redacting nothing you need for rebuilding. See the sibling topic on exporting data from PagerDuty for endpoint details and the fields that do not map directly. Done means every service and schedule in PagerDuty has a matching export file and a named owner.
Rebuild rotations and escalation steps in GoAlert
The on-call lead recreates services, rotations, schedules and escalation policies in GoAlert from the exports, checking each escalation step, timeout and notification channel against the PagerDuty original. Map alert sources to GoAlert's generic API, email, Grafana, Prometheus, Site24x7 or Sensu integrations, and rebuild any notification rules or integrations that have no direct equivalent by hand. Calendar subscriptions for team members are configured here too. Done means a side-by-side review signed off by the on-call lead lists no unmatched services or escalation steps.
Re-point Prometheus and Grafana alerts
The monitoring team changes the Alertmanager and Grafana contact point configuration so alerts are sent to the GoAlert integration endpoint for each service, and removes the PagerDuty receivers only after the new path is confirmed. Alerts that were routed by PagerDuty service keys need each key replaced with the matching GoAlert integration. Check that alert labels and severity fields still reach the right escalation policy. Done means a test alert from Prometheus and a test alert from Grafana each open an incident in GoAlert and page the expected responder.
Run parallel paging tests
Run both paging systems at the same time for a period your incident and on-call leads agree in writing, sending test alerts through each path and confirming that the right person is paged in the right order. Include escalation timeouts, acknowledgement and resolution, and failover when a primary responder does not answer. Record each test with the alert, the time sent and the time each responder was reached. Done means every test case has a recorded result and no gap is open against the PagerDuty behavior that responders rely on.
Cut over and document the paging path
The on-call lead switches production alerting to GoAlert as the only active paging path, keeps PagerDuty in read-only or inactive state until the agreed retention and export checks are complete, and updates the on-call runbook with the new escalation paths and contact points. Note what GoAlert does not cover, such as AIOps, status pages, runbook automation and post-incident tooling, and make sure those tools have an owner. Done means production pages route only through GoAlert and the runbook names the owner of each remaining function.
What drives the cost of self-hosted paging
The main cost difference is in what you pay for and how it recurs. PagerDuty bills through per-user and platform plan fees, and paid add-ons such as status pages or extra capabilities are priced separately, so the recurring line grows with headcount and with the features your team switches on. Ask the PagerDuty account team to itemize the base plan, each user type you need (responders versus stakeholders, for example), every add-on in the renewal, and any minimum commitment or multi-year term. Those line items are the baseline you compare against. GoAlert itself carries no license fee under its Apache 2.0 license, so your recurring costs are the components you run: compute for the GoAlert binary and its replicas, a managed or self-operated PostgreSQL service, Twilio voice and SMS charges, and the people who keep it running.
Several GoAlert costs are recurring and move with alert volume and team size. Twilio bills per message and per call, so the number of escalation steps, the number of responders each policy notifies and how often pages are retried all drive the monthly figure. Ask your Twilio account team for current SMS and voice rates for each destination country you page, and model them against last year's incident history. PostgreSQL is a hard requirement, and the getting started guide recommends PostgreSQL 17 or newer with the pgcrypto extension, so backup retention, storage and point-in-time recovery are ongoing costs. High availability is the largest design decision: one instance runs the default engine and the rest run with --api-only, and database switchover is supported with minimal disruption. Each extra instance, a second database node and cross-zone networking add recurring spend, and a paging system that must work during an outage usually needs them.
Engineering time is the cost most often left out of the comparison, and it is mostly one-time setup followed by recurring operation. Setup covers the data encryption key (which must be identical on every instance and needs a secure store), SSO wiring through GitHub OAuth or an OpenID Connect provider, Twilio account setup, migration of services, schedules and escalation policies, and parallel paging tests before cutover. Ongoing work covers upgrades (GoAlert v0.35.0 was released on September 21, 2026, so check the releases page for the version you intend to run), database maintenance, certificate and secret rotation and on-call for the paging stack itself. Before you request a quote from DeployOpen or any implementation partner, ask for the fixed-scope deliverables, the handover documentation, the hours assumed for high availability testing and the retainer terms for upgrades. Those are the items that decide your three-year total.
Questions buyers ask before moving off PagerDuty
How much effort does a move from PagerDuty to GoAlert take?
The effort depends mostly on how many services, escalation policies, schedules and integrations you run, and on how many of those integrations point at PagerDuty's own endpoints. Teams with a small set of services and simple weekly rotations usually have less to rebuild than teams with layered escalations, overrides and many monitoring sources. Effort also rises with the number of notification rules that must be re-created by hand, because PagerDuty's REST API export does not map one to one onto GoAlert's model. Ask for an inventory of services, schedules, escalation policies and integrations before any estimate is agreed, and confirm how your current PagerDuty setup maps to the features listed in the GoAlert documentation.
How long does the cutover take, and what sets the timeline?
No fixed duration is published for this move, so treat any number you hear as unverified until it is tied to a written scope. The main timeline drivers are the size of the inventory, the time needed to build and test the PostgreSQL and Twilio pieces, the identity integration for logins, and the period you need to run both systems in parallel. Parallel paging tests take real calendar time because each escalation path should be exercised with real on-call staff. Ask any implementation partner for a phased plan with dependencies and sign-off points rather than a single date.
Can our team migrate from PagerDuty to GoAlert without outside help?
Yes, a team with experience running PostgreSQL, container platforms and telephony integrations can do the work in house, since GoAlert ships as a single binary with Docker images and its only hard requirement is PostgreSQL. The harder parts are usually operational: designing high availability, protecting the data encryption key, wiring Twilio for voice and SMS, and testing escalations under real conditions. Outside help is most useful for a fixed-scope review of your current escalation design and for the parallel run. DeployOpen plans, implements and hardens self-hosted platforms in your own infrastructure under written scope, and the team can decide which parts to keep internal.
What does the move require from our PostgreSQL, Twilio, identity and on-call teams?
The move needs four inputs from you. From the database side, GoAlert requires PostgreSQL and recommends version 17 or newer for new installations, and it requires the pgcrypto extension. From telephony, Twilio is currently the only supported provider for voice and SMS notifications, so you need a Twilio account, numbers and the regulatory setup that applies to your destinations. For identity, GoAlert supports GitHub OAuth and any OpenID Connect provider, with Dex suggested to bridge other systems. From the business side, your on-call staff must confirm their contact methods and review the rebuilt schedules before cutover.
Does GoAlert replace PagerDuty status pages or AIOps features?
No, GoAlert covers on-call scheduling, automated escalations and notifications, not status pages, AIOps, runbook automation or post-incident tooling. If you rely on those PagerDuty features, plan a separate tool for each one and confirm its integration path with GoAlert before cutover. Self-hosted status page options are covered on a separate page, and OneUptime is a candidate if you want incident management and status pages in one product. Check the GoAlert documentation for the current list of alert sources, since it names generic API, email, Grafana, Prometheus, Site24x7 and Sensu.
How do we keep paging reliable during the cutover?
Run GoAlert in parallel with PagerDuty, route test alerts through both, and confirm that every escalation step reaches the right person before PagerDuty is switched off. Use one default engine instance and additional instances started with the --api-only flag for high availability, and confirm database switchover behavior in a test before relying on it. Keep the data encryption key identical on every instance, since GoAlert uses it to protect sensitive values such as API keys. Keep PagerDuty active until the parallel period ends, and keep a documented rollback path. Use your monitoring sources, such as Prometheus or Grafana, to confirm that alerts arrive at GoAlert.
What recurring costs remain after moving to GoAlert?
The recurring costs are the infrastructure to host GoAlert, the PostgreSQL service, Twilio message and call charges, and the staff time to operate and upgrade the system. GoAlert itself is Apache 2.0 licensed, so there is no per-user license fee, but you still pay for the components it depends on. Twilio charges depend on your volume and destinations, so ask for your expected usage profile and confirm current rates directly with Twilio. Compare these against your current PagerDuty per-user and add-on charges, and ask any partner for a written quote that separates one-time migration work from ongoing support and upgrades.
A decision path for choosing between the two
Start with the scope of the problem. If paging is the only need, meaning on-call rotations, escalation policies and SMS or voice notification, GoAlert covers that core directly: services, escalation policies, rotations, schedules and calendar subscriptions, with alert sources such as the generic API, email, Grafana, Prometheus, Site24x7 and Sensu. If your team also relies on PagerDuty for AIOps, status pages, runbook automation or post-incident review, list those features now and assign each one a replacement or a decision to drop it. Those gaps, not the paging engine, usually decide whether a migration is a clean swap or a multi-tool project.
Next, test whether your team can run the paging path as a dependency it trusts during an outage. GoAlert's only hard requirement is PostgreSQL, which must be version 17 or newer for new installations and must have the pgcrypto extension. Ask who owns backups, failover and the database switchover that the getting started guide describes, and whether that person can rehearse it. Also confirm the Twilio account that sends SMS and voice, because Twilio is currently the only supported provider for those notifications. Set the data encryption key once and keep it identical on every instance, since losing or mismatching it affects stored API keys. If nobody on the team can answer these questions with confidence, a self-hosted paging system adds risk rather than removing it.
Then decide where notifications must be processed. Data residency is often the strongest argument for self-hosting, but it is not automatic. GoAlert keeps schedules, users and contact data in your PostgreSQL database, while SMS and voice content still passes through Twilio, so confirm with your compliance team which regions and sub-processors that path involves. Finally, weigh the operating model. A fixed-scope implementation can cover hardening, high availability and parallel paging tests, and retainers can cover upgrades and monitoring, but the cost of those services should come from a written scope, not from assumptions. If the answers point to paging only, owned infrastructure and a team that can run PostgreSQL, GoAlert is a sound fit. If they point to a broad incident platform, plan the gaps before you start.
How DeployOpen helps evaluate and implement GoAlert
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including GoAlert. We start with a written scope that defines which PagerDuty capabilities move to GoAlert, which stay with you, and which you rebuild or drop.
How we scope
- Inventory which PagerDuty services, schedules, escalation policies and integrations your teams actually depend on.
- Confirm which alert sources, such as Prometheus, Grafana or email, must reach GoAlert during the migration.
- Agree in writing what is out of scope, including AIOps, status pages, runbook automation and post-incident tooling.
How we build
- Deploy GoAlert as a single binary or Docker image with PostgreSQL 17 or newer and the pgcrypto extension, inside your environment.
- Configure the data encryption key so the same key is applied on every instance, and set up one default engine with API-only instances for scale.
- Connect Twilio voice and SMS notifications, Slack steps and login through GitHub OAuth or your OpenID Connect provider, then test parallel paging.
How we hand over
- Document schedules, escalation policies, notification channels, encryption key handling and database switchover steps for your operators.
- Provide a parallel paging test record so you can confirm that on-call notifications reach the right people before PagerDuty is retired.
- Deliver runbooks for backups, upgrades and the Twilio account settings your team must own after handover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, and we quote from the written scope.
- Ask us to confirm GoAlert release changes, such as those in the GoAlert releases page, before you schedule an upgrade.
