Which fits after Opsgenie: GoAlert or Jira Service Management?
GoAlert fits teams that want on-call scheduling, escalation and SMS, voice, Slack and email alerting on infrastructure they run themselves. Jira Service Management fits teams already standardizing on Atlassian ITSM. Opsgenie reaches end of support on April 5, 2027, so the choice is which successor you can build, operate and test before that date. Both paths need the same first step: an inventory of schedules, escalation policies, integrations and the people who depend on them.
The decision turns on four things. First, how much of your toolchain already sits in Atlassian. If Jira, Confluence and Jira Service Management are already the system of record for incidents and change, Atlassian's destination keeps paging, tickets and post-incident work in one place. Second, in-house operations capacity. GoAlert's only hard requirement is a PostgreSQL database, and the getting started guide recommends PostgreSQL 17 or newer for new installations and the pgcrypto extension. Someone must own that database, the data encryption key shared by every instance, backups, upgrades and high availability of the paging path itself. Confirm that a named team has this skill and on-call coverage for it.
Third, notification providers. GoAlert currently supports Twilio as the only provider for SMS and voice, so you need a Twilio account, a contract that fits your regions and a plan for carrier delivery testing. Slack and email ingress through Mailgun or built-in SMTP are also supported. Fourth, whether paging is the whole job. If you need problem management, service catalog requests or change approvals tied to alerts, GoAlert will not replace those workflows, and Jira Service Management is the stronger fit. If paging, escalation and clear ownership are the gap you must close, GoAlert covers that scope on infrastructure you control.
Which option fits which team situation
This table matches common team situations to the better fit between self-hosted GoAlert and Jira Service Management, with the reason for each. The rows are illustrative, so read each one against your own tools, data rules and staffing, and treat the conditions to confirm as the points to settle before choosing.
| Team situation | Better fit | Reason and what to confirm |
|---|---|---|
| Already runs Jira Service Management for incidents and service desk | Jira Service Management | Incident, on-call and change records already live in one workflow. Confirm that the Jira Service Management licensing and on-call features cover your schedules and escalation needs before you commit. |
| Platform team with PostgreSQL and Kubernetes operations | GoAlert | GoAlert needs PostgreSQL as its only hard requirement, recommends PostgreSQL 17 or newer, and supports several instances with one in default engine mode and the rest API-only. Confirm your team can run database backups and failover. |
| Regulated team that must keep alert and contact data on its own servers | GoAlert | GoAlert is a single binary with Docker images, so it can run inside your own network, and sensitive values such as API keys can be encrypted with a data encryption key before they are stored. Confirm that your SMS and voice provider's data handling meets your rules, since Twilio is the only supported provider. |
| Team that depends on many Opsgenie integrations with other tools | Jira Service Management, unless your tools are covered | GoAlert's documented alert sources include a generic API, email, Grafana, Prometheus, Site24x7 and Sensu. Inventory every Opsgenie integration first, and confirm each one has a GoAlert path or a generic API route before choosing GoAlert. |
| Team whose notifications run mainly through Slack and email | GoAlert | GoAlert can notify a Slack channel as an escalation step and can create alerts from email through Mailgun or built-in SMTP ingress. Confirm that your Slack workspace and mail setup match these paths. |
| Team that needs phone and SMS paging for on-call engineers | GoAlert, with a Twilio account | GoAlert sends SMS and voice through Twilio. Your costs will include Twilio usage, which scales with notification volume. Confirm your country coverage and number provisioning with Twilio before cutover. |
| Organization that wants one vendor for ITSM, change and on-call | Jira Service Management | Keeping incidents, requests and on-call in one vendor reduces the number of contracts and integrations to manage. Confirm the total cost against your current Opsgenie and Jira spend. |
What GoAlert covers from Opsgenie's core on-call work
GoAlert covers the core on-call model that most Opsgenie teams depend on: services, escalation policies, rotations and schedules, along with calendar subscriptions so engineers can see their shifts in their own calendar apps. Automated escalations move an alert to the next responder when the first one does not acknowledge it, and notifications go out as SMS or voice calls. Slack channels can be an escalation step, so a policy can notify a channel before or after a person is paged. Email can also create alerts, either through Mailgun or through GoAlert's built-in SMTP ingress. The documentation lists alert sources including a generic API, email, Grafana, Prometheus, Site24x7 and Sensu. Map each of your Opsgenie schedules and escalation policies to one of these building blocks before you assume anything carries over.
The largest gap is the notification path. Twilio is currently the only supported provider for GoAlert voice and SMS, so every team that pages by phone needs a Twilio account, numbers and a sender configuration, and needs to confirm that its regions and phone numbers are usable for its on-call staff. If your Opsgenie setup uses another voice or SMS carrier, or relies on push notifications from a mobile app, confirm the current state of those features with the GoAlert maintainers before you commit. Also confirm that the escalation step you rely on in Opsgenie, such as a particular responder type, has an equivalent in GoAlert.
The second gap is the integration list. Opsgenie is often wired to many monitoring, chat and ticketing tools, and GoAlert's documented alert sources cover only a subset of those. Build an inventory of every Opsgenie integration that creates alerts, including API keys in use and any inbound email addresses, and mark each one as supported through the generic API, email, Grafana, Prometheus, Site24x7 or Sensu, or as a gap. Gaps need either a small adapter that posts to the generic API or a decision to accept a different routing path. Do not assume an Opsgenie feature exists in GoAlert until you have tested it in a staging instance.
Capability comparison: Opsgenie and GoAlert
This table sets Opsgenie's on-call capabilities against what GoAlert provides, row by row, so teams can see which functions carry over directly and which need a decision or a check. Where a GoAlert fact is documented, the cell states it; where Opsgenie details must be confirmed, the cell says what to check in Atlassian's current documentation and in your own integration inventory. Use the gaps column as your working list before cutover.
| Capability | Opsgenie (confirm before migrating) | GoAlert (self-hosted) |
|---|---|---|
| On-call schedules | Confirm the schedule types and time zone handling you rely on in Atlassian's current Opsgenie documentation | Supports on-call scheduling with rotations and calendar subscriptions |
| Rotations | Export your current rotation definitions and check them against Atlassian's documentation | Rotations are a documented object, re-created per team in GoAlert |
| Escalation policies | List every policy and step your teams use, including any repeat or notify-all behavior | Automated escalations are a core function; rebuild each policy and test each step |
| SMS and voice notifications | Confirm which SMS and voice providers and countries your account uses today | Twilio is the only supported provider for SMS and voice, so Twilio account and number setup is required |
| Slack notifications | Confirm which Slack workspace integration and channel routing you use | Can notify a Slack channel as an escalation policy step |
| Email alerts | Inventory the mailboxes and filters that create alerts today | Email alerts through Mailgun or a built-in SMTP ingress |
| Alert sources and integrations | Build the full inventory of connected tools and API keys from your own environment | Documented sources include a generic API, email, Grafana, Prometheus, Site24x7 and Sensu; check each one you use |
| Login and SSO | Confirm the SSO method your organization uses for Opsgenie access | GitHub OAuth and any OpenID Connect provider; Dex can bridge other identity systems |
| Licensing | Confirm your current Opsgenie plan terms and end of support date with Atlassian | Apache 2.0 licensed, distributed as a single binary with Docker images |
| Deployment model | Hosted by Atlassian; confirm the regional API host your data uses | Self-hosted in your infrastructure, with PostgreSQL as the only hard requirement |
Where alert and contact data lives under each option
Each option stores on-call schedules, contact details and alert payloads in a different place, and each depends on different third parties to deliver notifications. The cards below set out the GoAlert components a security or compliance reviewer needs to map, and the checks to run against Opsgenie's hosted terms before deciding.
Self-hosted runtime location
GoAlert ships as a single binary and as Docker images published as goalert/goalert, so the application runs wherever you deploy it, including your own cloud accounts, data centers or private networks. Every contact record, schedule and alert passes through infrastructure your team operates. For Opsgenie, which is a hosted Atlassian service, confirm with Atlassian which regional API host (US or EU) your tenant uses and what its data residency terms cover.
PostgreSQL as the data store
PostgreSQL is the only hard requirement, and it holds every schedule, escalation policy, user contact and alert record. Recommended for new installations is PostgreSQL 17 or newer. Your backup, retention, encryption at rest and point-in-time recovery plans must now cover this database, which previously sat inside Atlassian's service boundary.
pgcrypto extension dependency
GoAlert requires the pgcrypto extension in the database. Your database administrators need to confirm it is permitted on the managed PostgreSQL service you choose, because some hosted offerings restrict extensions. Add this to the platform checklist before the database is provisioned, since it can block installation rather than surface as a runtime fault.
Data encryption key management
GoAlert recommends a data encryption key so sensitive values such as API keys are encrypted before they are written to the database. The same key must be present on every instance. Treat the key as a high-value secret: store it in your secrets manager, define rotation and recovery procedures, and confirm that losing it does not strand encrypted integration credentials.
Login through OIDC or GitHub
GoAlert supports GitHub OAuth and any OpenID Connect provider for sign-in, and suggests Dex to bridge other identity systems. Responders' access therefore depends on your identity provider's availability and on who can administer it. Map which identity source controls account creation, deprovisioning and MFA, because those settings decide who can see on-call data and acknowledge pages.
Third-party notification carriers
Twilio is currently the only supported provider for GoAlert SMS and voice, so responder phone numbers leave your environment and reach Twilio. Email alerts can run through Mailgun or a built-in SMTP ingress, and Slack notifications go to Slack. Ask each provider for its data processing terms and regional options, and record them as sub-processors in your third-party risk register.
When Jira Service Management is the better fit
This path fits teams that already run Jira Service Management or follow Atlassian ITSM processes for incidents, requests and changes. If on-call routing is the only piece missing, adding it to a tool your service desk already uses can be simpler than operating a second system for paging. Atlassian takes on the hosting, upgrades and the integration between the queue and the on-call schedule, so your team keeps configuration ownership rather than running infrastructure.
- Existing licenses: Confirm how many agent and customer seats you already pay for, and whether on-call features are included in your current tier or added as a separate product.
- Shared workflows: Incident tickets, post-incident reviews and change approvals already live in Jira, so paging events can attach to records people already use.
- Vendor-managed upgrades: Atlassian handles platform releases, which reduces the patching you would otherwise schedule for GoAlert and PostgreSQL.
- Lock-in: Schedules, escalation logic and integrations become tied to Atlassian's data model, so ask how exports work before you commit.
- Licensing growth: Ask for the per-user price at your headcount, including any growth tiers, and whether responders who only receive alerts need a paid seat.
Before you decide, ask Atlassian for a written quote that lists every product, user type and add-on your on-call workflow needs.
This path fits organizations that want paging tied directly to change, incident and service desk records in one vendor path. When a deployment triggers an alert, the responder can see the related change, the affected service and the request history without switching systems. The effort moves to Atlassian's connected records, and your team spends less time building and maintaining custom links between tools.
- Change context: Alerts can point to the change that preceded them, which helps during incident reviews and post-change checks.
- Service ownership: Service catalog entries and their owners can drive who is paged, reducing stale routing tables.
- Audit trail: Incident, change and paging history sit in related records, which simplifies evidence gathering for an internal or external assessment. Confirm with your auditor what evidence format they accept.
- Lock-in on process: Your change and incident workflows adopt Atlassian's configuration model, so moving later means re-mapping process as well as data.
- Scope of licensing: Ask which modules are required for change and service desk features, since these are often priced separately from basic on-call.
Before you commit, map your current change and incident process to the Atlassian model and confirm which steps the platform cannot represent.
This path fits teams without the capacity to run a paging system themselves. A self-hosted GoAlert deployment needs a PostgreSQL database with the pgcrypto extension, a data encryption key shared across instances, identity configuration, Twilio accounts for SMS and voice, and monitoring of its own availability. If no one on your staff owns those components, a managed service may carry less operational risk than an unowned self-hosted system.
- Operations ownership: Atlassian operates the service, so responsibility for uptime, scaling and database maintenance shifts to the vendor under its terms.
- Notification delivery: Carrier relationships and telephony are handled by the provider rather than by a Twilio account your team must configure and monitor.
- Recurring cost: Subscription fees recur every year, while self-hosting moves costs to hosting, database administration and staff time.
- Dependency risk: You depend on the vendor's availability and roadmap, so confirm contractual uptime commitments and data return terms in writing.
- Support scope: Ask what support is included at your tier and what you pay for escalated incidents.
Before you choose this path, estimate who on your team would take a page at 3 a.m. for a paging failure, and confirm that person has the access and time to fix it.
This tab lists what to ask for in a written Jira Service Management quote before comparing it with GoAlert. Pricing for Atlassian products is set by the vendor and changes over time, so the figures must come from your own quote and not from this page. Comparing quotes on the same scope makes the decision traceable and gives you a baseline for a later renewal.
- Products and tiers: List each product, edition and add-on, and confirm which features your on-call schedules require.
- User types: Confirm how responders, stakeholders and read-only users are counted and billed.
- Term and renewal: Ask for the contract length, renewal price rules and any discount that ends after the first year.
- Data export: Request a written description of export formats for schedules, incidents and history, including any API limits.
- Exit terms: Ask what happens to your data at termination and how long you have to retrieve it.
Before you sign, compare the quote line by line with your planned GoAlert costs, including PostgreSQL hosting, Twilio usage and staff time.
What running GoAlert costs compared with an Opsgenie or Jira Service Management subscription
GoAlert is licensed under Apache 2.0, so the software itself carries no license fee. The recurring cost is what you run around it: a PostgreSQL database (the only hard requirement, with pgcrypto enabled), compute for one or more GoAlert instances, and notification charges for SMS and voice through Twilio, the only supported provider for those channels. Email-created alerts add a Mailgun account or your own SMTP ingress. Staff time is the largest cost and the hardest to predict: someone must own installation, upgrades, backups, the data encryption key and the high-availability layout. Ask your team to estimate those hours from your current on-call load, and treat the estimate as an internal figure until a written scope confirms it.
Some costs are one-time and some recur. One-time work includes exporting schedules and escalation data, rebuilding rotations and policies in GoAlert, re-pointing alert sources such as Prometheus or Grafana, and testing notifications before cutover. Recurring costs are hosting, Twilio usage that grows with the number of pages and voice calls you place, Mailgun volume if you use it, and ongoing upkeep. Your Twilio and Mailgun rates must come from their own rate cards, and you should model them against your last twelve months of paging volume rather than an average. Opsgenie and Jira Service Management costs are subscription terms that only Atlassian can state. Request the current order form, renewal terms, user tiers and any add-on pricing in writing, and confirm what the destination plan includes for on-call and notification volume, since those details decide the comparison.
Treat the comparison as a set of written numbers, not a headline price. For each option, list the subscription or hosting fee, the notification charges, the infrastructure and backup costs, the internal staff hours and the one-time migration effort. DeployOpen prepares a quote from a written scope that names the instances, database layout, notification providers, alert sources and integrations involved, so the scope should be settled first. Ask for the quote to separate one-time work from recurring support, and to state what a retainer covers once GoAlert is live.
How a move from Opsgenie to GoAlert runs, step by step
The sequence takes an Opsgenie estate from inventory to a tested GoAlert deployment that carries live on-call traffic, with Opsgenie retired only after the new paths are proven. Each step ends with a check you can verify before moving on.
Inventory services, schedules and integrations
Start by listing every Opsgenie team, service, schedule, escalation policy and integration, and record which alert sources feed each service. Name an owner for each team, usually the engineering or platform lead, who signs off on the inventory. Mark which routes carry production paging and which are low-priority, because those decide the test order later. The step is done when every service has a documented owner, a schedule, an escalation path and a list of inbound sources.
Export Opsgenie data before the deadline
Pull schedules, timelines and escalation data out of Opsgenie while the account is still active, using the export guides for schedules and API access. Store the exports in your own controlled location with the same access rules as other on-call records. Ask Atlassian to confirm the current export options and the data retention terms that apply to your plan, since undeleted data is removed after the shutdown date. The step is done when you can open each export and match it against the inventory from the previous step.
Stand up PostgreSQL and a GoAlert instance
Provision PostgreSQL 17 or newer, which GoAlert recommends for new installations, and enable the pgcrypto extension, the one hard database requirement. Deploy GoAlert as a single binary or from the published Docker image in a staging environment inside your own network. Generate one data encryption key and set it identically on every instance, because it protects sensitive values such as API keys before they reach the database. The step is done when the instance starts, connects to the database and serves its web interface.
Configure login and access
Connect GoAlert to your identity system using GitHub OAuth or an OpenID Connect provider. If your identity system is not OIDC-compatible, plan to bridge it through Dex, which the getting started guide suggests. Map existing Opsgenie roles to GoAlert administrators and responders, and restrict administrative access to a small group. The step is done when a test user from each responder group can sign in and sees only the services they are meant to manage.
Recreate services, rotations and escalation policies
Rebuild each service, rotation, schedule and escalation policy in GoAlert using the inventory and exports as the source of truth. Import or enter calendar subscriptions where the export supports them, and check every schedule against the Opsgenie original for shift times and time zones. Review escalation steps with the team leads so that timeouts and notification order match what responders expect. The step is done when a side-by-side review of each service shows matching coverage for the next several rotation periods.
Re-point alert sources and configure notification channels
Point each alert source at GoAlert, including the generic API, email, Grafana, Prometheus, Site24x7 or Sensu sources you use. Configure Twilio as the SMS and voice provider, which GoAlert currently supports as its only option, and confirm the sending numbers and account limits with Twilio. Connect Slack channels as escalation steps and set up email alert ingress through Mailgun or the built-in SMTP ingress. Keep the Opsgenie integrations active during this step. The step is done when a test alert from each source reaches the correct GoAlert service.
Run notifications in test and in parallel
Send test pages to each responder through SMS, voice, Slack and email, and record delivery and acknowledgement times. Then run GoAlert in parallel with Opsgenie for a defined period so that real alerts reach both systems and the team can compare who was paged and when. Ask responders to confirm they received each page on every channel they rely on. The step is done when each escalation path has delivered a test page to every responder and the parallel run shows no missed pages.
Cut over and retire Opsgenie
Switch alert sources to GoAlert as the primary path after the parallel run passes, and move the team's on-call calendars to GoAlert subscriptions. Keep the final Opsgenie exports and the configuration record as an archive, then disable the Opsgenie integrations and remove the account before the shutdown date. Confirm the GoAlert backups and the encryption key storage are in place before you close Opsgenie. The step is done when all alert sources route through GoAlert, no page goes to Opsgenie, and the archive is recorded.
Keeping a self-hosted paging system reliable
The main operational difference from Opsgenie is that your team now runs the paging system itself. GoAlert needs one hard dependency, a PostgreSQL database, and the getting started guide recommends PostgreSQL 17 or newer for new installations with the pgcrypto extension enabled. In a multi-instance deployment, such as a Kubernetes cluster, run one instance in the default engine mode and the rest with the --api-only flag, so exactly one process drives escalations. Plan the database switchover before you need it: the guide describes switchover with minimal disruption, so rehearse it in a non-production copy and confirm the exact steps against the GoAlert getting started guide.
Set the data encryption key before the first production write. GoAlert uses it to encrypt sensitive values such as API keys before they reach the database, and the same key must be configured on every instance. Store it in your secrets manager, document who can rotate it, and check that a restored database can still be decrypted with the key you hold. Applying releases is the other recurring task. The latest release supplied for this topic is v0.35.0, released September 21, 2026, so confirm the version you deploy against the releases page, read the release notes for schema or configuration changes, and upgrade a staging copy first. Because GoAlert ships as a single binary and as Docker images under goalert/goalert, your rollout path is the same one you already use for other internal services.
Two controls matter most. First, monitor the paging path itself: a dead escalation engine produces silence, not an alert. Watch the database, the instance health of every node, and the Twilio and Slack notification paths, and send a heartbeat from an independent system so a failure is visible even when GoAlert cannot page. Second, test notifications on a fixed schedule, such as a recurring test to each responder's SMS, voice and email, and a Slack escalation step. Record the results. Finally, decide who is on call for the paging system. Someone must own database health, key custody, upgrades and failed test follow-up, with a named backup. That ownership, not the software installation, is the largest effort difference from a hosted service.
Questions teams ask before choosing GoAlert or Jira Service Management
What does moving from Opsgenie to GoAlert cost?
The cost has two parts: the work to rebuild your on-call setup, and the platforms you run afterward. Migration effort depends on how many schedules, escalation policies, teams and alert integrations you have, and on whether you bring in a partner or staff the work internally. Running GoAlert needs a PostgreSQL database, which you host or buy, plus compute for the binary or containers, and a Twilio account for SMS and voice. Ask any quote to separate one-time migration work from recurring hosting and telephony costs, and to state which items are assumed and which are fixed. GoAlert's own project is Apache 2.0 licensed, so the software itself carries no license fee, according to its README.
How long does an Opsgenie to GoAlert migration take?
Duration is set by the size of your on-call estate and by the deadline. Opsgenie ends support on April 5, 2027, according to Atlassian's end of support timeline, so the export and cutover plan should be fixed well before then. The main drivers are the number of teams and rotations, the complexity of escalation chains, how many alert sources must be re-pointed, and how much notification testing your compliance or operations process requires. Ask for a timeline in the written scope that lists export, rebuild, parallel running and cutover as separate milestones.
Can our team migrate to GoAlert without an outside partner?
Yes, a team with PostgreSQL, container or Linux operations experience and someone who owns the on-call design can run the migration alone. GoAlert is a single binary with Docker images, and its getting started guide lists PostgreSQL 17 or newer, the pgcrypto extension and a shared data encryption key as the main setup requirements. What is harder in-house is the high availability design, the Twilio and email ingress setup, and testing every notification path before cutover. An outside partner is useful when you need a fixed-scope plan, documentation and evidence for an assessment, or staff who are already committed elsewhere.
What work does the migration need from our staff?
Your staff must supply knowledge that no export contains: who is on call for each service, which escalation steps are still used, and which alerts are noise. Engineers must confirm schedules and overrides, operations leads must approve the new escalation policies, and security staff should review the identity setup, since GoAlert supports GitHub OAuth and OpenID Connect login. Plan time for a parallel run where both systems receive test alerts, and for responders to practice acknowledging pages on the new system. Confirm these responsibilities in writing before work starts.
Does GoAlert cover the integrations we use with Opsgenie?
GoAlert covers the core on-call functions: services, escalation policies, rotations, schedules and calendar subscriptions, plus alert sources including a generic API, email, Grafana, Prometheus, Site24x7 and Sensu. It notifies Slack channels as an escalation step and accepts email alerts through Mailgun or a built-in SMTP ingress. Opsgenie has its own catalog of integrations, so list every one you use and check each against GoAlert's documentation. Any integration without a native source will need a generic API call or a custom bridge, and that work belongs in the scope.
What happens to Twilio and notification costs at higher volume?
Twilio is currently the only supported provider for GoAlert voice and SMS notifications, according to the GoAlert getting started guide, so your telephony bill is set by Twilio's own rates. Notification cost rises with the number of pages, the number of escalation steps that use SMS or voice, retries, and the number of responders per incident. Ask your provider and your partner to model message volume from your last year of Opsgenie alerts, and to reduce noisy alerts before cutover. Check Twilio's current pricing directly, since rates change and are not supplied here.
How do we get a quote, and what does the written scope include?
DeployOpen does not publish a price list. Most engagements are fixed-scope, and a quote follows from a written scope agreed before work starts. A useful scope lists the Opsgenie teams, schedules, escalation policies and integrations in the migration, the PostgreSQL and hosting environment, the notification providers, the testing and parallel-run plan, the cutover date, the documentation delivered, and any backup or upgrade work after go-live. Ask for each item to be marked in or out of scope, and ask whether ongoing support is priced as a separate retainer.
Is Jira Service Management the safer choice than GoAlert?
It is the lower-effort choice if your organization already runs Jira and wants Atlassian to host and maintain the platform, but it changes your licensing and your data location. Choose GoAlert when you need self-hosting in your own infrastructure, want to control paging data and telephony, or want to avoid a new SaaS commitment. Choose Jira Service Management when your ticketing, change and incident processes already live in Atlassian tools and you accept its subscription terms. Compare both options on total cost, data residency, integration coverage and the staff time your team can commit, and confirm current licensing with Atlassian.
How DeployOpen helps evaluate, implement and migrate to GoAlert
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including the on-call path from Opsgenie to GoAlert. We start from a written scope that sets out which schedules, escalation policies and alert sources move, and which do not.
How we scope
- We inventory Opsgenie teams, schedules, escalation policies and integrations before any build decision is made.
- We record which alert sources and notification channels, such as Twilio SMS and voice, must work in GoAlert at cutover.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy GoAlert as a single binary or Docker image on your infrastructure, backed by a PostgreSQL database with pgcrypto.
- We configure the data encryption key, identity login and multi-instance layout so notifications stay available during failover.
- We re-create rotations, escalation policies and Slack or email routes, then test each notification path before cutover.
How we hand over
- You receive documentation of the configured schedules, escalation paths, alert source mappings and runbooks for your on-call team.
- We run a cutover test plan with your responders and record results, so you can confirm each paging path works before Opsgenie ends.
- Credentials, encryption keys and backup procedures are handed over to named owners in your organization.
How we support
- Ongoing support, upgrades and continuous testing of the paging stack are available as a retainer.
- Upgrades to new GoAlert releases are scoped and tested in a non-production environment before they reach on-call.
- Quotes follow from the written scope, so ask us to itemize infrastructure, Twilio usage and labor separately.
