Find every tool still sending alerts to Opsgenie before you migrate

An Opsgenie account accumulates integrations over years. Some are live. Some point at tools you no longer run. A few were created by people who have left. When Opsgenie shuts off on 5 April 2027, every live integration goes dark at once.

The inventory is the migration surface. It is usually smaller than the list suggests, but you must find every tool still sending alerts before the deadline.

This process lists integrations, checks which ones actually fire, classifies them, and repoints them one at a time. You keep the old path enabled until the new one fires. Then you disable the old one.

List every integration in your Opsgenie account

Pull the full list of integrations configured in your Opsgenie account. This list defines the migration surface. It includes live tools, dead integrations, and entries left behind by former employees.

Generate an API key with Read and Configuration Access in Settings -> API key management. EU accounts must use api.eu.opsgenie.com instead of the global endpoint.

Run this command to export the integration list as TSV:

curl -s 'https://api.opsgenie.com/v2/integrations' \
  -H 'Authorization: GenieKey YOUR_KEY' | jq -r '.data[] | [.enabled, .type, .name, .teamId] | @tsv'

The output contains id, name, enabled, type, and teamId. Use query parameters like ?type=Prometheus or ?teamId=... to filter server-side if the list is large.

Filter out entries where enabled is false. These integrations are already off and are not sending alerts. Remove them from your tracking list immediately. They do not need migration.

Fetch one integration’s settings with GET /v2/integrations/{id} when the name alone does not tell you what it is.

Team-scoped integrations created by someone who left may not appear if you use a team API key. Use a global key from API key management so you see every integration in the account.

Save this list. It is your baseline. You will compare it against actual alert data in the next step to separate live tools from ghosts.

Check which enabled integrations actually fire

An enabled integration is only configuration until traffic arrives. Pull the recent alert history to find what fires.

curl -s 'https://api.opsgenie.com/v2/alerts?limit=100&sort=createdAt&order=desc' \
  -H 'Authorization: GenieKey YOUR_KEY' | jq -r '.data[] | [.createdAt, .integration.type, .integration.name, .source] | @tsv'

Each alert record carries the integration object (id, name, type) and the source. Group these by integration name. An enabled integration with no alert in the last 90 days is either a very quiet system or a dead one. Check which.

Page through the results using the offset parameter up to the limit you need. Alert history is what you lose on shutdown day, so save a copy for the record.

Compare this output against the integration list from the first step. Mark any enabled integration with zero hits in the window. Ask the owner whether the system behind it is quiet or gone before you disable anything: a backup job that fires twice a year is quiet, not dead.

What remains is the set of integrations that generate pages. That is the surface area for your migration.

Classify each live integration by type

Each integration has a protocol and a direction, and the type decides how you repoint it.

Webhook integrations are the most common. Tools like Prometheus Alertmanager, Grafana, Datadog, CloudWatch, Sentry, and uptime checkers send HTTP POST requests to an Opsgenie URL. That URL contains the integration key. Repoint these by updating the destination URL in the source tool to point at the new AlertKick endpoint. The key changes, but the flow remains the same.

Email integrations work differently. Something sends an email to an Opsgenie address, and Opsgenie parses it into an alert. The sender is often a cron job, a legacy script, or a system with no other output. Find the sender. If you do not, the email will bounce or go nowhere when Opsgenie shuts down. Trace the mail headers if the source is unknown.

API integrations are used by custom scripts. These scripts call the Opsgenie API directly to create alerts. Search your codebase for api.opsgenie.com and GenieKey. You will find the scripts that need their URL and key replaced. A simple hostname search usually finds them.

Heartbeats work the other way round. Opsgenie heartbeats expect a periodic ping to confirm a service is alive, and page you when the ping stops. They need a heartbeat monitor in the new tool, not a webhook.

Chat and ticketing integrations like Slack or Jira are usually outbound. They receive alerts from Opsgenie and post them to a channel or ticket. They do not send alerts to Opsgenie. They do not need repointing for inbound traffic. They may need configuration updates if the destination channel changes, but they are not part of the ingestion surface.

Classify each entry in your list. Note the source tool for webhooks, the sender for email, and the code location for scripts. Mark heartbeats for replacement. This classification determines the migration effort for each item.

Repoint integrations one at a time

Stand up the new destination first. In AlertKick each inbound integration has its own service key and a default severity, and 28 are available plus email ingestion for anything without a webhook. The catalogue is at /integrations/.

Point the lowest-stakes source first. Confirm an alert arrives and pages the right roster. Then move the next.

Leave the Opsgenie integration enabled until the new path has fired for real at least once. Then disable it in Opsgenie (do not delete; disabled is reversible).

Scripts that call the alert API need their URL and key replaced; a search for the old hostname finds them.

If the new path fails, the old one is still catching alerts, so you can fix it without losing coverage. Start with the sources that are easiest to verify and work up to the harder ones.

Keep a log of what you change: the old integration ID, the new one, and the time of the switch. When everything has moved, send a test alert from each source tool and watch it page in AlertKick.

Handle the things people forget

Heartbeats behave differently from webhooks. Opsgenie heartbeats expect a periodic ping to prove a system is alive, so nothing sends an alert; the absence of a ping is the alert. Replace them with heartbeat monitors and update the cron jobs that ping them. AlertKick heartbeats are described at /features/heartbeats/.

Email senders often have no clear owner. An integration might route alerts from a legacy system or a cron job that sends mail to an Opsgenie address. Find the sender by tracing the mail headers. Identify the source IP or the script path. Once you know what is sending the mail, point it to the new email ingestion endpoint or switch it to a webhook if the tool supports it.

Team-scoped integrations create blind spots. A team API key only lists that team’s integrations, so an integration created by someone who has left can hide in a team nobody looks at. Use a global key from API key management for the inventory.

Status pages, iCal feeds, and mobile app links often point directly at Opsgenie. They send no alerts, but they break on shutdown day all the same. Update each one to the new platform.

The output of this exercise is a short table: tool, integration type, last alert, owner, new destination, done. Put it with the migration runbook next to the schedule and policy import, and read the Opsgenie end-of-life guide if the destination is still undecided.