What you can export from PagerDuty before your contract ends
If a renewal, a pricing change or a data residency requirement is forcing you out of PagerDuty, the first question is what you can take with you. The documented route is the PagerDuty REST API, called on the US or EU host that your account is provisioned in. Through it you can pull services, schedules, escalation policies, users and incident history. That data gives you the structure of your on-call program and a record of how it behaved, which is what you need to rebuild paging in GoAlert and to answer post-incident questions later. Confirm the host with your account owner before you write any script, because calls to the wrong region will fail or return nothing useful.
Treat the export as the start of a rebuild, not a copy. Integrations, notification rules, user contact methods, and some account-level settings do not move as data you can import into GoAlert. Each service integration key that your monitoring tools send alerts to must be re-pointed at a GoAlert alert source, and notification rules must be recreated as GoAlert escalation steps and user contact settings. Make an inventory of every service integration and every rule before you export, so you can map each one to its GoAlert equivalent and spot gaps early. A short list of the monitoring systems that page you, with the owner of each, is often the most useful artifact you can produce at this stage.
Before you plan a cutover date, confirm the details that determine how much you can extract and when. The exact endpoints, pagination behavior, rate limits and how far back incident history is retained all depend on your PagerDuty plan and API documentation for your account, and they can change, so check them in PagerDuty's own API reference and with your account representative rather than relying on this page. Ask for an API token with read-only scope, run a test export of one service, and compare record counts against the PagerDuty interface. Export incident history with a retention plan in mind, because some older records may be unavailable depending on your contract.
Which PagerDuty objects export through the REST API and in what format
This table lists each PagerDuty object you need for a GoAlert rebuild, the REST API read endpoint that returns it, the JSON output, and the limits to confirm before you run a full export. Use it as a checklist, and confirm pagination, rate limits and date filters against the current PagerDuty REST API reference for your account's region. Integration keys and notification rules need separate calls, so plan those rows first.
| Object | REST API read endpoint | Output format | Limits to confirm |
|---|---|---|---|
| Services | GET /services, plus GET /services/{id}/integrations for integration keys | JSON list of service objects with escalation policy references | Pagination size and offset, and whether integration keys need a separate call with appropriate read scope |
| Schedules | GET /schedules with schedule layers included, and GET /schedules/{id} for detail | JSON with rotation layers, restrictions and time zone per schedule | Whether layers, overrides and final schedules come back in one response or need separate requests |
| Escalation policies | GET /escalation_policies with targets included | JSON with ordered escalation rules, delay values and target IDs | Delay units and how targets of type user, schedule or team are referenced in each rule |
| Users | GET /users, plus GET /users/{id}/contact_methods and GET /users/{id}/notification_rules | JSON user profiles, with contact methods and notification rules in separate responses | Whether contact methods and notification rules return for every user, and whether personal data fields can be excluded |
| Teams | GET /teams and GET /teams/{id}/members | JSON team objects with member references | Whether team membership is complete when the account uses nested or inherited teams |
| Incident history | GET /incidents with since and until query parameters, and GET /incidents/{id}/alerts | JSON incident records with status, service, urgency and timestamps | Maximum date range per request, retention period on your plan, and filter behavior on the US or EU host |
| Log entries | GET /log_entries with since and until query parameters | JSON audit records of acknowledgements, escalations and notifications | Retention window for log entries, pagination behavior, and whether older entries are available for your plan |
What does not come out cleanly and how to handle it
Services, schedules and users move through the REST API, but several things around them do not. Integration keys, notification settings, add-on configuration, automation and UI-bound notes all depend on PagerDuty's own system or on people. Each card below names the workaround and the checks to make before you cut over.
Integration keys and monitoring connections
PagerDuty integration keys are the routing tokens that Prometheus Alertmanager, Grafana and other sources use to send events. They are not a portable export, and a key copied from PagerDuty will not become a GoAlert credential. In GoAlert, alert sources such as the generic API, Prometheus and Grafana are configured on the GoAlert side, so each monitoring tool must be re-pointed and tested. Confirm which sources send to each service, and list every receiver in your monitoring configuration before you change it.
Notification rules and contact methods
PagerDuty stores each user's notification rules and contact methods, such as phone, SMS and push, with their delivery timing. The REST API can return much of this, but the exact rules often need a manual check against what people actually receive. In GoAlert, contact methods are entered per user and delivery goes through Twilio for voice and SMS. Ask each responder to confirm their numbers and delay settings, and send a test page to every person before go-live.
Add-on and analytics configuration
Features such as analytics dashboards, AIOps grouping, response play settings and paid add-ons are configured in PagerDuty's interface and are not always exposed through the REST API in full. Some of these settings have no GoAlert equivalent at all, so they should not be treated as data to migrate. Make an inventory of which add-ons your account uses, then decide for each whether to rebuild, replace or drop it. Confirm with PagerDuty which settings the API returns for your plan.
Custom fields and automation actions
Custom incident fields, automation actions and runbook steps usually live in PagerDuty's configuration rather than in the schedule or policy objects you export. If a team triggers scripts or links runbooks from incidents, that behavior stops at cutover. Document each automation trigger and its owner, and recreate the essential ones with your own tooling that calls the GoAlert API. Keep the exported JSON as a reference for the logic, since it will not run unchanged.
Incident notes and attachments
Incident timelines, notes and file attachments are tied to PagerDuty's incident UI and may be available only through specific endpoints or not at all, depending on the item. Plan for them as an archive rather than a migration target. Export what the API returns for incidents you need to keep for audit or post-incident review, store it read-only in your own systems, and confirm with PagerDuty what can be retrieved for attachments before the account is closed.
User credentials and MFA enrollments
Passwords, SSO links and multi-factor enrollments are held by the identity system and cannot be exported from PagerDuty. Responders will need to sign in to GoAlert through GitHub OAuth or an OpenID Connect provider, with Dex suggested to bridge other identity systems, and enroll their factors again where your identity provider requires it. Map each PagerDuty user to an identity in your directory, and confirm that every responder can sign in before the old account is disabled.
Choosing the US or EU API host for your account
Use the US host when your PagerDuty account was created in the US region. The account's services, schedules, escalation policies, users and incident history are stored in that region, so requests sent to the US host read the data your export needs. Confirm the region with the account owner before you configure any client, because the web application alone may not make the region obvious.
- Match the region first: Confirm the account was created in the US region before you write or run any request.
- Set one base URL: Point every export script, Postman collection or SDK at the US API host and keep it there for the whole run.
- Read errors as a region signal: Authentication failures or empty lists from a token that works in the web application can indicate that the wrong host is being called.
- Keep host and token together: Store the host beside the token in your export notes so later runs do not mix them.
Check the exact host name against PagerDuty's current API reference before the first request, because the script depends on that string being correct.
Use the EU host when your PagerDuty account was created in the EU region. The account's data is held in that region, so an export pointed at the EU host reads the complete account, while a request sent to the wrong region can fail or return partial results. Teams with EU data residency obligations often need to show that the export itself stayed on the EU host from start to finish, so keep that path documented.
- Match the region first: Confirm the account was created in the EU region before you configure any client.
- Use the EU host for every call: Include scheduled jobs, test requests and any one-off lookups, so no part of the export reaches the other region.
- Check the data path: Note where the export files are written and who can access them, since the API host alone does not decide where copies of the data end up.
- Watch for region errors: Authentication failures or empty results on a token that is valid in the web application can mean the host is wrong.
Ask the account owner to confirm the region in writing, and record that confirmation with your export files so later reviewers can trace the source.
The account and administrative settings show which region the account uses and the subdomain that identifies it. Before the export, a named administrator should confirm both, because the subdomain appears in links and support requests and helps match each export file to the correct account. Do not rely on memory or on another team's notes for this step.
- Account subdomain: Note the subdomain shown in the account address, since it identifies the source account in support requests and in your records.
- Region in settings: Look for the account region in the administrative settings and confirm it with the account owner.
- Token owner access: Confirm that the user who creates the API token can read the services, schedules, escalation policies, users and incidents you plan to export.
- Multiple accounts: If your organization runs more than one PagerDuty account, record which account holds each team's services and which one the export covers.
Ask the account owner to confirm these four items in writing so the export team starts from a verified source.
Write these details down before anyone runs a request. The record gives the team one fixed reference for every script and gives the people rebuilding services in GoAlert, and any later reviewer, a trace of which account and credentials produced each export file. Treat the record as part of the export output, not as a side note.
- Host: The full API host you will call, either the US or the EU host, copied from the documentation you checked.
- Account subdomain: The subdomain that identifies the source account, confirmed in the account settings.
- Token scope: The access level granted to the token, the user it belongs to and the date it was created.
- Token owner and removal: Who holds the token, where it is stored and when it will be revoked after the export is complete.
- Run log: The date, the operator and the object types pulled in each run.
Store this record in your secrets manager or change system, not in the export script or in a shared document with open access.
Moving a PagerDuty account from one region to the other is a separate migration that PagerDuty performs on its side, and it carries its own cost and terms. This export only reads from the region where the account already exists, so it does not move data between regions or change the host your account uses. Keep the two pieces of work apart in your planning so a region question does not stall the export.
- Separate commitment: Confirm the scope, terms and cost of any region move directly with PagerDuty, since they are outside this export.
- Export before any region work: Pull a complete copy from the current region first, so you hold a record if the account changes during a migration.
- Ask what carries over: Ask PagerDuty what the migration keeps, including users and incident history, and get the answer in writing.
- Re-check the host afterward: Any export run after a region change must use the host for the new region.
- Plan for a possible gap: Ask whether alerts or on-call changes are paused during the migration, and plan coverage for that window.
Raise any region question with PagerDuty's account team before you schedule the export, because the answer determines which host you use.
The export sequence, step by step
This sequence pulls the objects GoAlert needs to be rebuilt, in dependency order, and produces a dated, checksummed archive you can compare against later. Each step leaves a file you can inspect before the next one starts, so gaps appear early. Nothing in the sequence changes data in PagerDuty.
Inventory the account and confirm the host
Before any call is made, the account owner lists the services, teams, schedules, escalation policies and users in scope, and records which regional host the account uses, either the US or EU API host. Write the host and account name into a
README.mdin the export folder. Confirm the host against the current PagerDuty REST API reference, since the base URL must match the region where the account was created. The step is done when the inventory lists every object type and the host is written down.Create a read-only API token
An administrator creates a REST API token in PagerDuty with the narrowest read-only scope the documentation allows for this account type. Store the token in a secrets manager or a shell environment variable, not in a script or repository. Confirm which read permissions your plan exposes for users, schedules, escalation policies, services and incidents, because the available scopes can vary. The step is done when a test read call returns a successful response and a write call is refused.
Export users and teams
Call the users and teams list endpoints and page through every result, saving the raw responses to
users.jsonandteams.json. Users come first because schedules, escalation policies and services all reference them by identifier. Confirm the pagination parameters and the field that signals another page in the current API reference, and keep requesting pages until that signal is clear. The step is done when the record count matches the number shown in the PagerDuty interface for users and teams.Export schedules with their layers
Retrieve the on-call schedules, including their rotation layers, restrictions and overrides, and save the output to
schedules.json. Schedules reference users, so the user identifiers from the previous file should resolve. Confirm whether overrides and future-dated layers are returned by default or need a parameter, because a default call can omit them. The step is done when each schedule has its layers and every referenced user identifier appears inusers.json.Export escalation policies
Retrieve the escalation policies with their levels, targets and timeouts, and save them to
escalation-policies.json. Each target can be a user, a schedule or another escalation target type, so check that every referenced identifier exists in the earlier files. Confirm the timeout units and the target type values in the current reference before you map them to GoAlert. The step is done when every escalation level resolves to a known user or schedule.Export services and their integrations
Retrieve services, which link to escalation policies and teams, and save them to
services.json. Request the integration list for each service as a separate call if the service response does not include it, and keep those results in the same file. Integrations hold the routing keys that monitoring tools send alerts to, and they do not transfer to GoAlert. Confirm which integration fields the API returns for your account. The step is done when each service lists its escalation policy and every integration key is recorded for the rebuild.Export incident history over a date range
Request incidents for a defined date range, one range at a time, and save each range to a file named with its start and end dates, for example
incidents-2024-01-01_2024-03-31.json. Confirm the maximum range the endpoint accepts and the status values it returns, including resolved and acknowledged incidents. Use the same paging approach as before and keep the raw responses. The step is done when the record counts for each range match the counts visible in the PagerDuty incident log.Store each response unchanged with checksums
Keep every response exactly as received, without editing, reformatting or merging fields. Record the export time in UTC and generate a SHA-256 checksum for each file with
sha256sum, writing the results toMANIFEST.sha256. Store the folder in read-only, access-controlled storage and keep a copy outside the migration workstation. Notification rules and integration settings still have to be rebuilt by hand in GoAlert, so list them in a separaterebuild-checklist.md. The step is done when a second person can verify every checksum from the manifest.
How to verify the export before you rely on it
Verify the export in three layers before any GoAlert instance pages a real responder. First, compare record counts for each object type (services, escalation policies, users, schedules and rotations) against what the PagerDuty web interface shows for the same account. A mismatch usually means a filter, a pagination step or a deleted object was missed, so resolve every difference before moving on. Keep the counts in a short written record so the same comparison can be repeated after any re-run of the export.
Second, spot-check who is on call. Pick a sample of past dates, such as a holiday rotation and a handover week, and a sample of future dates that cover upcoming shift changes. For each date, record the on-call user for each escalation level in PagerDuty, then check the same date in GoAlert's schedule view. Include at least one override and one timezone boundary, because these are where rebuilt schedules most often drift. Ask the team leads to confirm the results, since they know the rota intent better than any export.
Third, test escalation paths in a non-production GoAlert instance, never the live one. Trigger test alerts for each service, confirm that every step notifies the intended person or Slack channel, and confirm that the timeout between steps matches the PagerDuty policy. Only Twilio is supported for SMS and voice in GoAlert, so run these tests against a Twilio sandbox or a restricted number list agreed with your telecom owner. Incident history is an archive, not a working dataset: verify it by sampling a few incidents per service and checking their timestamps, status and assignees, then keep the raw export files unchanged. Confirm retention rules for those files with your compliance owner before you delete anything from PagerDuty.
What to plan before the PagerDuty renewal or termination
Exporting data is the easy part when the calendar is wrong. The items below set the dates, the parallel paging window and the people you need on side before the PagerDuty contract ends. Read your order form and notice terms first, because they fix the deadlines everything else depends on.
Export completion date
Work backward from the contract end date in your PagerDuty order form. Set a firm date by which the REST API export of services, schedules, escalation policies, users and incident history must be finished and checked. Leave time to re-run the export, since the data you pull in week one will change as teams keep editing services and schedules. Confirm the notice period for non-renewal in writing, as auto-renewal clauses often start earlier than the date people remember.
Parallel paging window
Plan a period where both PagerDuty and GoAlert page the same on-call users, so you can test escalation timing, SMS and voice delivery and acknowledgement handling before PagerDuty goes quiet. Decide how long the overlap runs and who signs off that it worked. During the overlap, one team should be clearly named as the source of truth for who is on call, so two tools do not disagree during an outage.
Monitoring integration change calendar
Each monitoring source that sends events to PagerDuty, such as Prometheus, Grafana or cloud alerting, needs its routing changed to GoAlert. Build a dated change calendar listing each integration, its owner, the cut-over date and the rollback step. Integration keys and webhook settings are not carried over by the export, so the calendar should show every place a key is created or replaced. Schedule changes outside peak release windows.
Stakeholders and on-call users
List every responder, escalation owner, service owner and manager who receives pages or is named in a policy. Notify them before the cut-over, explain which tool to use for acknowledgement and where the schedule now lives, and confirm each person's phone number and notification preferences in GoAlert. Include the people who receive status or stakeholder communication from PagerDuty, since their workflows change as well.
Data retention and deletion request
After termination, ask PagerDuty in writing how long your account data and incident history are retained and when deletion occurs, and request confirmation of the deletion timing. Do not assume the deadline from the contract end date. Record the request, the reply and the date it was confirmed, because your own records policy may need that evidence.
Read-only archive approval
Decide whether you need to keep an archive of exported services, schedules and incident history for audit or post-incident review, and get approval from the data owner and security or compliance lead. Store the archive in your own infrastructure with access limits, retention rules and a named owner. Note that exported files may contain personal data, such as names and contact details, so the approval should cover how that data is protected and when it is removed.
Questions teams ask before exporting from PagerDuty
Can our team export data from PagerDuty ourselves?
Yes, most teams can pull the core objects themselves, because PagerDuty exposes services, schedules, escalation policies, users and incidents through its REST API on the US or EU host. The work is scripting and checking the output, not a special vendor process. What you still need is a token with enough read access, someone who understands your rotations, and time to compare exported data against what the live account shows. Integrations and notification rules are not a simple copy into GoAlert, so plan for that rebuild regardless of who does the export.
What does the export need from our team?
The export needs four things from your side:
- An API token owned by an account with read access to the objects you want to pull, and a decision about who owns that token afterward.
- An administrator who can confirm which services, teams and escalation policies are still in use.
- On-call owners who verify that each exported schedule and rotation matches the real coverage they expect.
- A reviewer for the data handling, since exports contain user contact details and incident records that may fall under your privacy and retention rules.
Revoke the token once the export is verified.
How long does an export take, and what drives the duration?
The duration depends mainly on the number of services, schedules, escalation policies and users, the number of integrations to document, and how much incident history you keep. Incident history is usually the largest volume because it is paginated through the API and must be stored and checked. Account structure and the amount of manual verification also matter more than raw data size. Ask any partner or internal team to state the duration in the written scope, tied to the object counts you provide, rather than accepting a general estimate.
What does an export cost internally compared with an implementation partner?
Internal cost is mostly engineering and on-call owner time: scripting the API pulls, mapping objects to GoAlert's services, schedules and escalation policies, and verifying results. An implementation partner adds a fixed-scope fee for the same work plus planning and handover documentation. Recurring costs in either case are small compared with the one-time effort, but the GoAlert runtime, PostgreSQL and Twilio message and call charges continue after the export. Ask for the cost broken into export, rebuild, verification and handover, and confirm which items are one-time and which recur.
Can we move our full incident history into GoAlert?
You can archive incident history, but you cannot recreate it as live incidents in GoAlert. Past incidents are records that you can store, index and search, typically in an external archive or data store that your team controls. GoAlert manages active alerts and on-call state, so historical records do not replay into it. Confirm with your compliance owner how long records must be retained and where the archive will live before choosing the format.
Can GoAlert take our PagerDuty integrations as they are?
No, integrations cannot be imported as they are. Each monitoring source, email route and chat or webhook connection must be reconnected to GoAlert's own alert sources, such as its generic API, email, Grafana, Prometheus, Site24x7 and Sensu options. Credentials and routing rules need to be recreated and tested one by one. Inventory every integration during the export so the rebuild list is complete before you cut over paging.
What should we ask for in a written scope before starting?
Ask for a written scope that names the exact objects in scope, such as services, schedules, escalation policies, users and the incident history window, and the format of each export. Require a list of integrations to reconnect, the notification channels GoAlert will use, and the test plan for parallel paging. Also ask who owns the API token, how credentials are stored, what happens to exported data, and which deliverables close the engagement, including documentation and handover. The scope should state the acceptance criteria, so you know when the export is complete.
How DeployOpen scopes and delivers a PagerDuty data export
DeployOpen treats a PagerDuty export as a fixed-scope engagement with written deliverables. We plan the extraction from the REST API on the correct US or EU host, build the transformation into GoAlert objects, and document what must be recreated by hand, such as integrations and notification rules.
How we scope
- Confirm whether your PagerDuty account sits on the US or EU host before any extraction begins.
- Inventory services, schedules, escalation policies, users and incident history that the written scope will cover.
- List monitoring integrations and notification rules that must be re-created manually in GoAlert.
How we build
- Script read-only API pulls with scoped credentials, paginated and logged, so the source account stays unchanged.
- Map PagerDuty schedules and escalation steps onto GoAlert rotations, schedules and escalation policies.
- Test imported data against a non-production GoAlert instance backed by PostgreSQL before any cutover.
How we hand over
- Deliver a written field-by-field mapping showing what transferred, what was transformed and what was skipped.
- Provide a rebuild checklist for integrations, notification rules and Twilio configuration, with owners named.
- Document data encryption key handling and the retention position for exported incident history.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if you want it.
- Agree in writing how post-cutover mapping errors are reported, reviewed and corrected.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
