Skip to content

Import from Opsgenie or PagerDuty

Admin, then Import (the page is titled “Migrate from Opsgenie or PagerDuty”, and the Migrate tiles in the integration catalogue lead here) copies an existing on-call setup into AlertKick: users, on-call schedules as rosters, and escalation policies. It is built around a preview, so nothing is created until you have seen exactly what will be.

Opsgenie’s end of support is 5 April 2027; the migration guide covers the timeline and the comparison pages set out what changes when you switch.

Opsgenie: Settings, then API key management, create a key with Read and Configuration Access ticked. Integration keys, and keys without Configuration Access, get a 403 on schedules. Note whether your account is in the US or EU region.

PagerDuty: Integrations, then API Access Keys, create a read-only REST API key.

The key is used for the fetch and never stored. Revoke it at the source when you are done.

Choose the provider (and, for Opsgenie, the region), paste the key, and choose Preview import. AlertKick fetches users, schedules, and escalation policies and shows the plan in three sections:

  • Users: matched to AlertKick users by email address, with the unmatched ones listed. Nobody is created behind your back - invite the missing people under Users and preview again.
  • Schedules to rosters - “X of Y will import”, with a note on each schedule that changes or is skipped.
  • Escalation policies - “X of Y will import”, with columns for the policy, its levels, repeat count, status, and notes.

Nothing is written at this stage.

SourceAlertKickNotes
UsersUsersMatched by email; unmatched are listed, not created
SchedulesRostersThe first rotation layer with a daily or weekly hand-off, including every-N-days and every-N-weeks lengths, with timezone, hand-off day and time. Other layers, time restrictions, end dates, and disabled schedules are recorded as notes on the roster. Hourly rotations and odd-length turns are skipped.
Escalation policiesEscalation policiesEach rule becomes a level: user targets page that user, schedule targets page whoever is on call in the imported roster, wait times become per-level timeouts, repeat loops carry over (capped at 10). Team targets are skipped; Opsgenie if-not-closed conditions and non-default notifyType values are noted.
Trigger notificationsOn-trigger and on-resolve notificationsNew policies are seeded so the first target hears about new alerts immediately, not only after the first timeout

Reasons you will see in the notes: rotation ended at the source; unsupported rotation type (only daily and weekly import); hand-off interval above AlertKick’s maximum; no member matched; “a roster with this name already exists; skipped (rename or delete it to re-import)”, and the same for policies.

Import N rosters and M policies creates them. The result card lists what was created, what was skipped, and any warnings. Re-running is safe: existing names are skipped rather than overwritten, so the usual loop is preview, invite the missing users, import, and import again for anything that skipped for lack of members.

  1. Open each roster and check the rotation against the source, especially hand-off time and timezone, and add any layers or overrides that were noted rather than imported.
  2. Open each policy and set the channels per level - the source’s per-user notification rules do not carry across; each person sets their own channels under Settings.
  3. Press Send Test Alert on each policy and watch it climb.
  4. Point one alert source at AlertKick - Prometheus Alertmanager, Grafana, Datadog, CloudWatch, and the rest are under Inbound alert sources - and run both systems in parallel before moving the rest.

Heartbeats (recreate them under Heartbeats), integrations and their keys, alert history, incident history, and per-user notification rules. Voice-call steps have no equivalent, because AlertKick does not place automated calls.