Replacing Opsgenie on a Small Team (Without an On-Call Rotation)

What's happening to Opsgenie

Atlassian stopped selling Opsgenie on June 4, 2025. On April 5, 2027 the product shuts down: nobody can log in, and any data that hasn't been moved is deleted. Atlassian's own path forward is to fold alerting and on-call into Jira Service Management (or Compass), with a migration tool for configuration and history.

That path makes sense if you already live in Jira Service Management. For a five-person team that just wanted "tell #ops when checkout breaks", it means adopting a service-desk product to keep doing something small.

What small teams actually used it for

Opsgenie is an on-call product, but plenty of teams only ever touched a slice of it. Look at your account and be honest about which list you're in:

• The slice: an API integration or two, a few heartbeats for cron jobs, alerts deduplicated by alias, and notifications landing in Slack, Microsoft Teams or email. Everyone sees the channel; whoever's around picks it up.
• The full product: on-call schedules with rotations, escalation policies ("page Ana, then Luis after 10 minutes"), phone calls, SMS and mobile push that wake someone up at 3am.

If you're in the first list, most of what Opsgenie did for you is ingestion, deduplication and routing. Those are much easier to replace than the second list.

Where Sigtake fits, and where it doesn't

Sigtake takes alerts from your code and tools, collapses repeats into one incident, and routes each one to the team that owns it, by email, Slack, Microsoft Teams and in-app notifications. It also has uptime checks and signal monitors, including heartbeats.

Two smaller gaps to know before you start:

• Alerts are opened over the API, not closed over it. There is one ingest endpoint. Acknowledging and resolving happen in the app. If your monitoring auto-closed Opsgenie alerts, that step becomes manual.
• There are no prebuilt integrations for Grafana, Datadog or Prometheus Alertmanager. Anything that can send an HTTP request with your own JSON body and headers can call Sigtake directly. Tools with a fixed webhook format need a small relay in between.

Opsgenie → Sigtake concept map

Most of the work in a migration is translating fields. Here is how each Opsgenie concept lands:

The alias trap

In Opsgenie you control deduplication: send the same alias and the open alert's count goes up. Sigtake has no alias field. It fingerprints every alert from source, title and severity, and folds a repeat into the open incident with the same fingerprint.

Two consequences matter when you port your senders:

• Keep titles stable. An order ID, timestamp or hostname inside the title makes every occurrence unique, and you're back to one alert per event. Put variable data in payload.
• Severity is part of the identity. If a sender escalates the same problem from high to critical, that opens a second incident rather than updating the first.

Repeats don't re-notify every time either. Sigtake notifies at occurrences 1, 10, 25, 50 and 100, then every 100. The deduplication guide covers this in detail.

How to migrate

1. Take inventory in Opsgenie

   Before touching Sigtake, list what's live in Opsgenie: every integration that sends alerts and who owns it, every heartbeat, every team, and every schedule or escalation policy that's actually used. If that last list isn't empty, re-read the warning above before going further.

2. Recreate your teams and projects

   In Sigtake, a project is an environment (production, staging) and a team is a group of people who own alerts. Create a project per environment under Projects. Under Teams, create each team and add it to the projects it covers. Sigtake gives every team a six-character team_code (such as K7Q2XD): that's what your senders will put in each alert. Invite people from Users.

3. Connect where alerts should land

   Under Channels, add your Slack, Microsoft Teams or email channels for each project. Then open the team and attach them under Channels. This replaces Opsgenie's routing and notification rules: a team's alerts go to that team's channels, in the alert's own project.

4. Create an API key per project

   Under API Keys, create one key for each project. It's shown once, so put it straight into your secret manager. An admin role is required.

5. Point your senders at Sigtake

   Each place that calls the Opsgenie Alert API gets a Sigtake call next to it. A typical Opsgenie request:

   curl -X POST https://api.opsgenie.com/v2/alerts \
     -H "Authorization: GenieKey $OPSGENIE_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "message": "Checkout latency above threshold",
       "alias": "checkout-latency",
       "priority": "P2",
       "source": "checkout-api",
       "responders": [{ "name": "ops", "type": "team" }],
       "details": { "p95_ms": "2400" }
     }'

   The same alert sent to Sigtake:

   curl -X POST https://api.sigtake.com/api/ingest \
     -H "X-Api-Key: $SIGTAKE_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "title": "Checkout latency above threshold",
       "severity": "high",
       "source": "checkout-api",
       "team_code": "K7Q2XD",
       "payload": { "p95_ms": 2400 }
     }'

   From application code, the Node and Python SDKs wrap the same call and retry on rate limits and server errors:

   import { Sigtake } from '@sigtake/sdk';
   
   const sigtake = new Sigtake({ apiKey: process.env.SIGTAKE_API_KEY });
   
   sigtake.alerts
     .ingest({
       title: 'Checkout latency above threshold',
       severity: 'high',
       source: 'checkout-api',
       team_code: 'K7Q2XD',
       payload: { p95_ms: 2400 },
     })
     .catch((err) => console.warn('sigtake ingest failed', err));

   If a team code isn't assigned to the key's project, the call fails with TEAM_NOT_IN_PROJECT. Fix it from the team's Projects section. Full request and response details are in the API docs.

6. Move your heartbeats

   An Opsgenie heartbeat becomes a signal monitor with a Missing signal rule ("alert if no readings arrive in X minutes"). Create the monitor under Signals, have your job send a reading when it finishes, and add the rule.

   Send a reading before adding the rule

   A monitor that has never received a reading counts as missing straight away. Send one first so the rule doesn't fire the moment you save it.

Run both before you cut over

Don't switch senders over in one go. For a week or two, send every alert to both Opsgenie and Sigtake, and compare:

• Does every alert that shows up in Opsgenie also show up in Sigtake? A missing one is a sender you didn't find in step 1.
• Do repeats fold the way you expect? If one Opsgenie alert turns into many Sigtake alerts, a title contains variable data.
• Does each alert reach the right Slack channel or inbox? If not, check which team the team_code points at and which channels that team has.
• Did each heartbeat stay quiet while its job ran, and fire when you paused it on purpose?

Once a full week passes with no differences, remove the Opsgenie calls.

Before April 5, 2027

• Export any alert history you want to keep for postmortems or audits. Atlassian deletes whatever hasn't been migrated at shutdown.
• Disable Opsgenie integrations once senders are switched, so nothing keeps writing to an account that's about to disappear.
• Remove Opsgenie API keys from your secret store and CI variables.

None of this needs to happen at the last minute. A small team with a handful of senders can run the whole migration, parallel run included, in two or three weeks.