Opsgenie escalation policies explained: delay, condition, notifyType and repeat

Opsgenie support ends 5 April 2027. Escalation policies are the part of an on-call setup that most often gets rebuilt wrong. Three of their settings mean something different from what most people assume.

An escalation has a name, an optional description, an owner team, a list of rules, and a repeat block. Each rule has four parts: condition, notifyType, delay, and recipient. Getting these mappings wrong stretches a 25-minute chain to 35 minutes or leaves alerts open indefinitely.

Audit your current policies before the deadline. The mechanics below show how to rebuild the behavior in another tool without surprises.

The shape of an Opsgenie escalation

The structure comes from the GET /v2/escalations endpoint. The API returns a flat list of rules. Each rule defines a single notification event. The delay field controls when that event happens. The condition field controls whether it happens at all. The notifyType field controls who receives the notification. The recipient field controls the target.

Each of those four fields hides a semantic that does not survive a copy-paste into another tool. The next sections take them one at a time.

Delay is absolute, not relative

Opsgenie measures delay.timeAmount from alert creation, not from the previous rule’s completion. The unit is minutes. This absolute timing breaks most migrations because modern tools use relative per-level timeouts.

Consider an escalation with three rules:

• Rule 0: 0 minutes
• Rule 1: 10 minutes
• Rule 2: 25 minutes

In Opsgenie, these fire at creation, 10 minutes after creation, and 25 minutes after creation. The gap between Rule 1 and Rule 2 is 15 minutes, not 25.

Most on-call tools wait N minutes after the previous level before triggering the next. Copying Opsgenie numbers directly stretches the chain. The example above becomes a 0-minute, 10-minute, and 25-minute delay between levels. The total time to reach the final recipient jumps from 25 minutes to 35 minutes.

Calculate the differences between consecutive absolute delays to rebuild correctly. The timeout for level n is delay(n) - delay(n-1). The first level always fires immediately.

Using the example above:

• Level 1: immediate (0 - 0)
• Level 2: 10 minutes (10 - 0)
• Level 3: 15 minutes (25 - 10)

Getting this math wrong changes the urgency of the escalation. A policy designed to reach a senior engineer within 25 minutes may take 35 minutes or more with a naive translation. Convert absolute timestamps into gaps before configuring the new tool.

if-not-acked versus if-not-closed

Opsgenie escalation rules include a condition that determines when the next level fires. The default is if-not-acked. This means the rule triggers only if the alert has not been acknowledged. If an engineer clicks “Acknowledge,” the escalation chain stops. The alert remains open, but no further notifications are sent.

The alternative is if-not-closed. With this setting, the rule fires unless the alert is fully closed. Acknowledging the alert does not stop the chain. The system continues to page the next recipient until someone closes the ticket. Teams use this for “keep nagging until fixed” policies.

Most on-call tools implement only the acknowledged semantic. If your Opsgenie policy uses if-not-closed, mapping it to the default setting stops the escalation at the first acknowledgement, which is a different policy.

Before rebuilding, decide whether the extra nagging was doing real work or was noise. If it was noise, use the standard if-not-acked behavior and move on. If it was doing real work, the honest replacement is a process rule (an acknowledged alert gets a status update within a set time) rather than a setting, because most tools have nowhere to put it. Write the decision down; it changes what “acknowledge” means to the people on the rota.

notifyType and recipient resolution

The notifyType setting determines which person or group on the recipient receives the notification. Most tools offer one “on-call” target. Opsgenie offers several variations that do not map one-to-one.

default is the standard. It routes to whoever is currently on call in the schedule or team. This has a clean equivalent in any roster-based tool.

next and previous are less common. next targets the person who will be on call in the next rotation. previous targets the person who was on call before. Teams often use these as a poor-man’s secondary rotation. A tool with a single roster cannot replicate this directly. Create a second roster and assign it to a second level in the escalation policy. Do not try to force a single schedule to handle primary and secondary rotations simultaneously.

users, admins, all, and random target specific subsets of a team. users notifies every member. admins notifies only team administrators. all notifies everyone in the team. random picks one person at random. If you see them, ask whether the alert should go to a specific role instead of a broad group.

Recipient resolution adds another layer of complexity. Opsgenie supports three recipient types: user, schedule, and team.

A user recipient is a named person. A schedule recipient is a rotation. Both migrate cleanly.

A team recipient is the hardest to migrate. When you specify a team, Opsgenie resolves “the team” to its on-call configuration at the moment the alert fires. That resolution happens inside Opsgenie, so the new tool cannot see it. Replace each team recipient with the concrete schedule or person the team resolves to today.

How the repeat block works

The repeat block controls how long an escalation policy keeps paging after the final rule fires. It re-runs the whole rule chain; it has nothing to do with retrying a failed notification.

The block has four settings: count, waitInterval, resetRecipientStates, and closeAlertAfterAll.

count defines how many times the entire rule set runs again. If the count is 13, the policy executes the rules 13 additional times after the initial pass.

waitInterval sets the pause in minutes between each repeat cycle. A value of 0 means no pause; the rules fire back-to-back. A value of 15 means the system waits 15 minutes before starting the next cycle.

resetRecipientStates clears acknowledged or seen flags on each repeat. This forces people to receive the notification again, even if they already handled it in the previous cycle.

closeAlertAfterAll automatically closes the alert once all repeats are complete. This is dangerous. An alert can close without anyone looking at it if the final repeat fires while no one is on call. Use this only if you are certain the alert is resolved by the time the repeats finish.

Consider a policy with a 60-minute rule chain, a repeat count of 13, and a wait interval of 15 minutes. Each repeat waits 15 minutes and then runs the whole 60-minute chain again, so the 13 repeats add 13 * 75 = 975 minutes. That is about 16 hours of paging on top of the first hour.

Most tools have no equivalent for closeAlertAfterAll. They keep alerts open until a human resolves them, and the notifications stopping does not mean the incident is fixed. When rebuilding, pick a repeat count the team would accept at 03:00 and verify the total paging window with a test alert.

Rebuilding the worked example

The source policy defines four rules and a repeat block. The goal is to map this to a tool that uses per-level timeouts.

Rule 1

• Delay: 0 minutes
• Recipient: Schedule “Platform Primary”
• Condition: if-not-acked
• Notify Type: default

Level 1 fires immediately on the primary schedule.

Rule 2

• Delay: 10 minutes
• Recipient: Schedule “Platform Secondary”
• Condition: if-not-acked
• Notify Type: next

The absolute delay is 10 minutes. The timeout for this level is 10 - 0 = 10 minutes. The notifyType is next, which roster-based tools do not have. If the intent was “the other person on the secondary rota”, the clean rebuild is a second roster on this level. If the intent was just to escalate, the schedule recipient is enough.

Rule 3

• Delay: 25 minutes
• Recipient: User [email protected]
• Condition: if-not-closed

The absolute delay is 25 minutes. The timeout is 25 - 10 = 15 minutes. The condition is if-not-closed, so in Opsgenie this rule fires even after an acknowledgement. Most tools cannot express that. Decide whether the extra nagging is needed before you rebuild the level.

Rule 4

• Delay: 60 minutes
• Recipient: Team “platform”
• Notify Type: all

The absolute delay is 60 minutes. The timeout is 60 - 25 = 35 minutes. The recipient is a team, so resolve “platform” to the concrete schedule or people it means. The notifyType is all: everyone in the team was paged at this point. Decide whether that is still what you want.

Repeat Block

• Count: 13
• Wait Interval: 15 minutes
• Close Alert After All: true

A repeat count of 13 with a 15-minute wait and a 60-minute chain is about 16 hours of paging. Cap it at a number the team can tolerate, and do not carry closeAlertAfterAll across: an alert that closes itself while nobody looked is worse than one that stays open.

Final Configuration

1. Level 1: Platform Primary, immediately.
2. Level 2: Platform Secondary, after 10 minutes.
3. Level 3: Bob, after 15 more minutes (decide what to do about if-not-closed).
4. Level 4: the platform team’s on-call schedule, after 35 more minutes.
5. Repeat: a count you would accept at 03:00, no auto-close.

Test the entire chain with a synthetic alert. Verify each level fires at the correct time and condition.

How AlertKick handles the import

The importer at Admin -> Import converts absolute delays to per-level timeouts automatically. It enforces a minimum timeout of 1 minute. This prevents accidental immediate re-paging in the new system.

Schedule recipients become roster levels. User recipients become notify-user levels. Team recipients are skipped with a note, because the import cannot know which schedule or person the team resolves to. Add that level by hand after the import.

if-not-closed and non-default notifyType values are shown as notes in the preview. The importer does not translate these automatically. It flags them so you can decide whether the extra nagging was doing real work or was noise. Make an explicit choice before creating the policy.

Repeat count carries over, capped at 10. waitInterval and closeAlertAfterAll are noted and not applied. AlertKick keeps an alert open until it is resolved.

Every policy has a Send Test Alert button. This runs the whole chain with a synthetic alert. Use this to verify the timeout gaps, the recipient resolution, and the condition logic. Do not turn off the old Opsgenie policy until the test alert confirms each level fires correctly.

The import is a starting point. It surfaces the ambiguities; you supply the context the API cannot see. Escalation policies in AlertKick are described at /features/on-call/ and the importer at /migrate/.

Checklist before turning off Opsgenie

Do not disable the old Opsgenie policy until the new chain is verified. Work through this checklist per policy.

1. Write each rule as “at minute X, notify Y, unless Z”. Translate the absolute delays into a plain sentence. For the worked example: “At minute 0, notify Platform Primary unless acknowledged. At minute 10, notify Platform Secondary unless acknowledged.” This forces you to check the timing logic before touching the tool.

2. Convert to gaps. Opsgenie uses absolute times. Most other tools use per-level timeouts. Calculate the difference between each rule.

   • Rule 1: 0 minutes.
   • Rule 2: 10 - 0 = 10 minutes.
   • Rule 3: 25 - 10 = 15 minutes.
   • Rule 4: 60 - 25 = 35 minutes. Enter these gaps into the new tool. If you enter the absolute values, the chain stretches to 35 minutes instead of 25.

3. Resolve every team recipient to a schedule or person. Replace “team platform” with the specific schedule or user the team resolves to. If the import skipped a team recipient, fill in the blank before testing.

4. Decide what to do about if-not-closed rules. If the original policy used if-not-closed, decide whether the extra nagging was necessary. If not, the standard acknowledgement stop is the right rebuild.

5. Set a repeat count you would accept at 03:00. A repeat count of 13 with a 15-minute wait on a 60-minute chain is a 16-hour paging window. The repeat block controls the noise, not how long the incident lasts.

6. Send a test alert through every level and confirm each one arrived. Send Test Alert runs the entire chain with a synthetic alert. Check the gaps, the recipients, and what acknowledging does. Do not turn off the Opsgenie policy until this passes. The deadline background is in the Opsgenie end-of-life guide.