Where self-hosted PagerDuty costs less and where it costs more
A renewal or a per-user price change is often what starts a cost review of on-call paging. Replacing PagerDuty's on-call scheduling and escalation with GoAlert removes the per-user license line, but the cost does not disappear: it moves into hosting, a PostgreSQL database, Twilio charges for voice and SMS, and the engineering time to keep a paging system running during outages. GoAlert is licensed under Apache 2.0, so the software itself carries no license fee, and the latest release, v0.35.0, came out on September 21, 2026. Whether the move is cheaper depends on three things: how many people sit in rotations, how many notifications the team sends in a typical month, and how much availability engineering the team must build around GoAlert.
Start by pricing your own components rather than comparing headline numbers. Ask PagerDuty for a written quote that covers the seats, add-ons and plan tier you actually use, and list every item that recurs each year. On the GoAlert side, list the compute for at least two instances (GoAlert recommends one instance in default engine mode and the rest with --api-only when running several), a managed or self-run PostgreSQL 17 or newer with the pgcrypto extension, backups, and the Twilio account that carries every SMS and voice call. Twilio is the only supported provider for voice and SMS, so its per-message and per-minute rates scale directly with notification volume. Confirm current Twilio rates for your destination countries on Twilio's own price pages, because those rates are not part of this analysis.
The costs that are easiest to underestimate are the ones that only appear during an incident. A paging system must still work when the primary database or cluster is degraded, so the team has to design failover, test database switchover and rehearse parallel paging before cutover. Those tasks are one-time effort, but keeping the system patched, rotating the data encryption key that GoAlert uses for sensitive values such as API keys, and maintaining Twilio credentials are recurring. Budget that engineering time explicitly, and get a fixed-scope estimate in writing before deciding, since the answer changes sharply with seat count and notification volume.
Cost components on each side of the comparison
This table lists each cost component of running PagerDuty against running self-hosted GoAlert, with who receives the money and whether the cost is one-time or recurring. No PagerDuty or Twilio prices are shown, so the right-hand column tells you what to request in a written quote. The main takeaway is that GoAlert removes the license fee but moves paging reliability, database operations and Twilio billing onto your own budget and staff.
| Cost component | PagerDuty (SaaS) | Self-hosted GoAlert |
|---|---|---|
| Software subscription or license | Recurring per-user fees and platform plan fees; confirm tier, user types and add-on pricing in the vendor order form | No license fee; GoAlert is Apache 2.0, so the recurring cost is the infrastructure and staff that run it |
| Paid add-ons and features | Recurring; status pages, advanced on-call features and similar capabilities may be add-ons or plan-only, so confirm which ones you rely on | Not applicable as licensed add-ons; capabilities GoAlert does not provide must be built or bought separately |
| Hosting infrastructure | Included in the subscription; no servers for you to size or patch | Recurring; compute for GoAlert instances, load balancing and backups in your own cloud, data center or air-gapped network |
| PostgreSQL database | Not applicable to you; the vendor runs the data store | Recurring; managed or self-run PostgreSQL 17 or newer with the pgcrypto extension, plus backups and failover testing |
| Twilio message and call charges | Included in the vendor's notification pricing, which you should confirm in writing | Recurring and usage-based; you hold the Twilio account and pay per SMS and voice call, so volume during incidents drives cost |
| High availability design | Delivered by the vendor as part of the service; ask for its published availability commitments | One-time design plus recurring run cost: multiple instances, one default engine and the rest in API-only mode, and a tested database switchover path |
| Implementation and migration | One-time effort to configure services, schedules and escalation policies, plus any exports and rebuilt integrations | One-time effort to deploy, set the data encryption key, configure login, rebuild schedules and re-point alert sources such as Prometheus and Grafana |
| Support and upgrades | Recurring vendor support as part of the subscription tier; confirm response terms in writing | Recurring internal effort or a retainer for upgrades, security patches and on-call coverage for the paging system itself |
What moves the cost comparison up or down
The cost gap between PagerDuty and self-hosted GoAlert depends less on list prices than on how many people, messages and availability targets your team actually runs. Each driver below changes which side of the comparison carries more of the total, so check them against your own rotation and paging history before requesting quotes.
Responders and schedule count
PagerDuty bills per user on its plans, so every responder who appears in a rotation adds recurring seat cost. GoAlert is licensed under Apache 2.0 with no per-user fee, so its cost does not rise with headcount in the same way, though your effort to maintain schedules and overrides does. Count active responders, shadow users, and the number of distinct schedules and escalation policies, since complex layered rotations raise the operating burden on either side.
SMS and voice notification volume
Notification volume is the cost line most likely to surprise you on a self-hosted stack, because GoAlert's voice and SMS delivery runs through Twilio, which bills per message and per call. Pull twelve months of PagerDuty notification counts by channel, then model how many pages a noisy alert source generates during an incident. Ask Twilio for current regional rates for your destination countries before you assume the saving.
PagerDuty add-ons you actually use
Platform plans and paid add-ons such as status pages, AIOps event intelligence and runbook automation are priced separately from base paging. If your team only uses scheduling, escalation and phone or SMS paging, those add-ons are removable cost. If you rely on them, GoAlert does not replace them, so the comparison must add a second tool or keep the add-on line in your quote. Ask PagerDuty to itemize each add-on on the renewal order form.
Availability target and instance count
A paging system must stay up during the outages it is meant to report. GoAlert's getting started guide describes running several instances, with one in the default engine mode and the rest using the --api-only flag, for example in a Kubernetes cluster. Higher availability targets increase the number of instances, the load balancing, the monitoring of the paging path itself and the test effort, all of which add to the self-hosted side. Define the target in writing before sizing the design.
PostgreSQL operating model
PostgreSQL is the only hard requirement for GoAlert, and the guide recommends PostgreSQL 17 or newer for new installations with the pgcrypto extension. A managed database service adds a recurring fee but moves backups, patching and failover to the provider, while a self-managed cluster shifts that work to your staff. Decide which model you run before comparing totals, because it often outweighs the GoAlert software cost itself.
In-house on-call skills
Running a paging system you depend on during outages requires people who can operate PostgreSQL, Kubernetes or your hosting platform, manage encryption keys, and maintain the Twilio account and phone numbers. Teams with this skill in-house see a smaller incremental cost, while teams that must hire or contract for it see the effort line grow. Check who is on call for the paging platform itself, and whether a DeployOpen engagement with a fixed written scope would cover setup, hardening or runbooks in your environment.
How to build the comparison with your own numbers
This sequence turns PagerDuty's invoice, your incident history and your Twilio rate sheet into a three-year cost view that compares the two paging options on the same basis. Each step produces a figure you can check against the next one.
Export current PagerDuty seats, tiers and add-ons
The account owner or finance contact pulls the last twelve months of PagerDuty invoices and the current order form. Record the number of user seats by role, the plan tier, any paid add-ons such as status pages or AIOps features, and the billing term and renewal date. Note which charges are fixed and which vary with usage. The step is done when every line on the invoice maps to a seat count, a plan, or an add-on, and nothing is left unexplained.
Pull incident and notification history from PagerDuty
An engineer with a read-only API token uses the PagerDuty REST API on the US or EU host to export incidents, services and escalation policies for the period you want to model. Count the notifications each service sends by channel, mainly SMS, voice and push, and separate out-of-hours pages. Where the API does not give a field you need, export the incident log from the web console and note the gap. The output is a monthly notification count by channel that reflects your real paging load, not an estimate.
Estimate future notification volume
The engineering manager and an on-call lead take the historical counts and adjust them for planned changes, such as new services, team growth or alert tuning that you expect to reduce noise. Document each assumption next to the number it changes so reviewers can challenge it. Keep a low and a high case, because paging volume during a major outage can be far above the monthly average. The step is complete when you have one volume table with stated assumptions for each year of the model.
Price Twilio usage from your own rate sheet
Ask Twilio, through your account team or the rate card in your console, for written per-message and per-minute prices for each destination country you page. Multiply the volume table from the previous step by those rates, and add any phone number rental fees for the sender numbers you will hold. Twilio is the only supported provider for GoAlert voice and SMS, so this line is a cost you carry directly. The output is a monthly and annual Twilio figure with the rate source written beside it.
Size PostgreSQL and redundant GoAlert instances
The platform engineering lead chooses where GoAlert and PostgreSQL run, and how many GoAlert instances sit behind a load balancer, following the getting started guide's advice of one default-mode instance and the rest with the --api-only flag. List the compute, storage, backup and monitoring resources for each environment and include a second site or failover database if your availability target needs it. Use your cloud or data center provider's current price list for each item. The output is a bill of materials with an owner and a source price for every row.
Add engineering hours for operating the paging system
Team leads estimate the hours per month for patching GoAlert releases, upgrading PostgreSQL, rotating the data encryption key, managing identity integration, testing failover and running the paging system's own on-call rota. Include the people who would cover a GoAlert outage, because a paging system must not depend on itself. Price these hours at your internal loaded rate. Record the assumptions, and note that the cost of a missed page during an outage is a business cost you should estimate separately. The step closes when you have an hours table and a cost figure per year.
Run the three-year comparison and ask vendors for written terms
Build a spreadsheet with one column for PagerDuty and one for self-hosted GoAlert, each with one-time setup costs and recurring costs for years one to three. Include the PagerDuty contract term and any minimum commitment shown in the order form, and compare these with the GoAlert cost lines from the previous steps. Before you finish, request written rate cards from PagerDuty and Twilio and an implementation quote from DeployOpen based on a written scope. The result is a three-year view you can defend in a renewal or budget review.
How GoAlert, PostgreSQL and Twilio fit together
GoAlert ships as a single binary, with Docker images published for each release as goalert/goalert. Its only hard requirement is a PostgreSQL database, and the getting started guide recommends PostgreSQL 17 or newer for new installations and requires the pgcrypto extension. Voice and SMS notifications go through Twilio, which is currently the only supported provider. So the cost stack has three parts you run or pay for directly: the GoAlert hosts, the PostgreSQL service, and the Twilio account that carries every call and text. Confirm the PostgreSQL version your platform team can support before you size anything, because that choice sets how much database operations work lands on your side.
Paging has to keep working during the outages it exists to report, so redundancy is part of the design, not an optional extra. For multiple instances, such as in a Kubernetes cluster, the getting started guide recommends running one instance in the default engine mode and the rest with the --api-only flag. The engine instance handles escalations and notifications, while the API-only instances serve the web interface and API. Set the same data encryption key on every instance, because GoAlert uses it to encrypt sensitive values such as API keys before they reach the database. Also plan database switchover, which the guide says is supported with minimal disruption, and rehearse it.
The cost of redundancy is a sizing decision, and no fixed figure applies to every team. Each extra instance, each database replica and any separate paging region adds hosting and operations time, while the Twilio spend depends on how many notifications your escalation policies generate during an incident. Ask your own platform team and your Twilio account representative to model peak paging volume, the number of instances needed for your availability target, and who on-call will be for the database itself. Put those inputs into a written scope, so the quote and the runbook reflect the same design.
Questions buyers ask about PagerDuty and GoAlert costs
How much effort does it take to run a self-hosted GoAlert?
Running GoAlert is mainly a matter of operating one hard dependency and a messaging provider. GoAlert ships as a single binary with Docker images for each release, and its getting started guide names PostgreSQL as the only hard requirement, recommending PostgreSQL 17 or newer and the pgcrypto extension. Ongoing effort covers upgrades to new GoAlert releases (v0.35.0 is the latest version we can point to), database backups and restore tests, the data encryption key, and monitoring the paging path itself. Ask your own platform team to estimate hours per month against this list, because the volume of work depends on how many services, rotations and escalation policies you run.
Can our team run GoAlert without outside help?
Yes, if your team already runs PostgreSQL, container platforms and identity integration in production. The install itself is documented in the getting started guide, and GoAlert supports GitHub OAuth and any OpenID Connect provider for login. The harder parts are high availability design (one instance in default engine mode and the rest with the --api-only flag, plus database switchover), Twilio account setup for SMS and voice, and testing escalations end to end. Teams without that background often bring in an implementation partner for a fixed-scope build. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your infrastructure under a written scope, and offers ongoing support as a retainer.
How long does a migration from PagerDuty take, and what drives that time?
The timeline depends on the size of your on-call estate and how much you rebuild by hand, and no fixed duration is established for this move. The main drivers are the number of services, escalation policies, rotations and schedules to recreate in GoAlert, the number of monitoring integrations to re-point (such as Prometheus and Grafana alert sources), and how much parallel paging you run before cutover. Notification rules and some integrations are not carried over automatically, so budget for manual rebuilding. Ask any provider, including DeployOpen, for a timeline in the written scope rather than relying on a general figure.
Does GoAlert have a license fee?
GoAlert is licensed under Apache 2.0, and the project does not charge a subscription. Your cost is the infrastructure it runs on and the services it calls: hosting, PostgreSQL, and Twilio message and call charges for SMS and voice, since Twilio is the only supported provider for those notifications. Check the current Apache 2.0 terms in the GoAlert repository before you rely on them for your own compliance review, and confirm Twilio's rates directly with Twilio for your countries and volumes, because they vary by destination and channel.
Which costs recur after a GoAlert deployment goes live?
Recurring costs fall into four groups. First, compute and storage for GoAlert instances and the PostgreSQL database, including the high availability pair or cluster you choose. Second, Twilio usage for every SMS and voice notification, which grows with the number of responders and the frequency of paging. Third, staff time for upgrades, backups, access reviews and on-call for the paging system itself. Fourth, any retainer for ongoing support or testing. PagerDuty's recurring costs are per-user and platform fees, so compare them with your own seat count, add-on needs and notification volume rather than list prices.
What should we request in a quote for a self-hosted GoAlert project?
Ask for a written scope that lists each deliverable, so the price follows from the work rather than from an assumption. Include the number of services, escalation policies, schedules and users to migrate, the identity integration, the database and high availability design, backup and restore testing, Twilio configuration, and the monitoring integrations to re-point. Request a separate line for any ongoing support or upgrade retainer, and ask how parallel paging tests are counted. Also ask what the provider needs from your staff and what you must confirm yourself, such as Twilio and PagerDuty contract terms and data export limits.
What operational risk does a self-hosted paging system carry?
The main risk is that the paging system fails during the outage it is meant to report. GoAlert depends on PostgreSQL and on Twilio for SMS and voice, so a database outage, a credential problem or a Twilio issue can stop notifications. Reduce that risk with a multi-instance design, tested database switchover, a documented data encryption key shared across instances, and a regular test that pages a real responder through every escalation path. Confirm your own failover targets and whether a secondary notification channel is needed, since those choices affect both reliability and recurring cost.
What to ask for in a quote for the paging migration
Ask for the scope in writing before any work starts, because a paging migration is only as complete as its list of systems. The written scope should name every service, escalation policy, schedule and user group being moved from PagerDuty, and it should list each monitoring source that pages today, including the Prometheus and Grafana alert paths that must be re-pointed at GoAlert's alert sources. Ask the provider to state which integrations are in scope, which are out, and who will confirm the list against your current PagerDuty configuration. Also ask how calendar subscriptions and notification rules will be rebuilt, since those are often missed in a first inventory and are not carried over automatically.
Next, ask for the high availability design and the PostgreSQL setup as separate line items. The quote should say how many GoAlert instances will run, which one holds the default engine mode and which run with --api-only, how the data encryption key is generated, stored and shared across instances, and how database switchover is tested. On the PostgreSQL side, confirm the version (the getting started guide recommends PostgreSQL 17 or newer for new installations), the pgcrypto extension, backup and restore testing, and who owns patching. For Twilio, ask who opens and pays the account, who manages sender numbers and voice settings, and how credentials are stored. Each of these items recurs in your operating cost, so ask for them to be priced and owned explicitly.
Finally, ask for a parallel paging test plan, runbooks and a handover. The plan should define how both systems page the same test incident, how responders confirm delivery by SMS and voice, how failover between instances is exercised, and when PagerDuty is switched off. Runbooks should cover on-call rota changes, escalation edits, Twilio failures and database recovery, written for the people who will be paged at 3 a.m. Ask for a named handover session and a support option after go-live. Ongoing support, upgrades and continuous testing are available as a retainer, and you should ask whether it is priced separately from the fixed-scope migration so that the one-time and recurring costs stay visible.
How DeployOpen scopes a fixed-price GoAlert implementation
DeployOpen approaches PagerDuty cost vs self-hosted GoAlert as a written, fixed-scope engagement inside your own infrastructure. We plan the paging stack, build and test it against your real escalation paths, and hand over documentation and runbooks your on-call team can operate.
How we scope
- We inventory current PagerDuty services, schedules, escalation policies and monitoring integrations before any cost comparison.
- The written scope names the hosting target, PostgreSQL setup, Twilio account ownership and the number of GoAlert instances.
- We agree in writing which notification paths, alert sources and identity login methods are in and out of the engagement.
How we build
- We deploy GoAlert as a single binary or Docker image with PostgreSQL 17 or newer and the pgcrypto extension.
- We set a data encryption key, shared across every instance, so API keys and other sensitive values are encrypted before storage.
- We configure one default engine instance with the remaining instances in API-only mode, then test database switchover and parallel paging drills.
How we hand over
- You receive architecture, cost component and high availability documentation covering PostgreSQL, Twilio and hosting charges.
- Runbooks cover rotation changes, escalation edits, key rotation and paging failure response for your on-call engineers.
- We walk your operations and security staff through the configuration, so the team can run the system without us.
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 after handover.
- Confirm with us the upgrade cadence and support hours you need before signing, since these shape the retainer scope.
