Opsgenie Escalation Policies and Notification Rules Explained

Cross-posted from the Fluidify blog.

When an Opsgenie alert pages the wrong person, or nobody, the cause is almost always in one of three places: a team routing rule, an escalation policy, or someone's personal notification rules. They're separate settings owned by different people, and they only make sense together. This guide explains how an Opsgenie escalation policy works, how notification rules decide which phone actually rings, the plan limits on each, and how to carry both over when you leave Opsgenie before its April 5, 2027 shutdown.

Key takeaways

• An Opsgenie escalation policy is an ordered list of rules. Each rule has a condition (alert not acknowledged, or not closed), a delay, and recipients, and the policy can repeat up to 20 times.
• Notification rules are per user. They decide how a person is notified (push, SMS, voice, email) and in what order once an escalation reaches them. Only the first matching rule for an event is used.
• Next or previous user in schedule, random team member, and escalation repeats aren't available on Free, Essentials, or JSM Standard. Free and Essentials users also can't create custom notification rules.

How an alert reaches a person in Opsgenie

It helps to see the whole path before looking at each setting:

1. An alert is created with one or more responders, usually a team, sometimes an escalation policy or a schedule directly.
2. Team routing rules decide what happens for that team. A routing rule matches on alert conditions and time of day, and routes the alert to an escalation policy, a schedule, or nobody.
3. The escalation policy decides who is notified, in what order, and after how long, until someone acknowledges or closes the alert.
4. Each recipient's notification rules decide which of their contact methods are used and with what delays.

A page that never arrives can fail at any of those four steps, which is why debugging Opsgenie means checking them in order.

Opsgenie escalation policies explained

An escalation policy is defined under a team's On-call settings or through the Escalation API. Atlassian creates a default escalation policy for every team, which is used whenever that team is added to an alert. Per Atlassian's documentation, each policy is a set of rules, and each rule has three parts.

Condition: each rule fires only if the alert is still "not acknowledged" or still "not closed," depending on which you pick. Most teams use "not acknowledged" so escalation stops when someone takes ownership. "Not closed" keeps escalating even after an acknowledgement, which is useful for high-severity alerts where acknowledging without fixing isn't enough.

Delay: how long to wait before the rule fires. Atlassian's own default-policy example (on-call user right away, next user after 5 minutes, all members after 10) reads as delays measured from when the alert was created, not from the previous rule, so set them as cumulative times and confirm the behavior with a test alert.

Recipients: who the rule notifies. The options are:

• A specific user.
• A team, in which case that team's routing rules decide the targets.
• All members of a team.
• The on-call user of a schedule.
• The next or previous on-call user of a schedule.
• A random member of a team.
• Team admins or users, in the default policy only.

Atlassian's example default policy notifies the on-call user right away, the next user in the rotation after 5 minutes if the alert is still open, and all team members after 10 minutes.

Repeating an escalation

When the last rule's delay has passed, the policy can start over after a repeat interval you set. Atlassian says an escalation can repeat at most 20 times for a single alert. Two options change how repeats behave:

Revert acknowledge and seen states on each repeat: if checked, responders are notified on the next repeat even if they already acknowledged or saw the alert. Use this sparingly, because it's how a team ends up paging someone who's already working the problem.

Close the alert after all repeats: if checked, Opsgenie closes the alert automatically once the repeats are done, even if it was acknowledged. That's convenient for noisy, self-resolving alerts and dangerous for real incidents, since a closed alert looks handled.

Escalation features by plan

Atlassian's docs say Free, Essentials, and Jira Service Management Standard don't include group notifications (deprecated anyway), next or previous user in schedule, random team member, or repeats. On those plans an escalation policy is a fixed list of users, teams, and schedules with delays. If you're moving to JSM and rely on repeats or "next user," check which JSM tier your quote is for. Our Opsgenie pricing guide covers the tier differences.

Opsgenie notification rules explained

Escalation decides who. Notification rules decide how. Every Opsgenie user has their own set, and they're the part most often forgotten in a migration because they belong to individuals, not teams.

Events: a notification rule is attached to an event. Opsgenie has eight notification events, including New Alert (an alert you're a recipient of was created), Schedule Start, and Schedule End. Schedule rules can fire just before your shift, or 15 minutes, 1 hour, or 1 day ahead.

Conditions: for alert events, a rule can match any or all of a set of conditions, such as priority or tags. That's how someone gets a phone call for P1 alerts but only a push notification for P4.

Time restrictions: a rule can apply only during certain hours, every day or on specific days. Windows can cross midnight, so a 19:00 to 11:00 window covers 16 hours.

Steps: within a rule, contact methods are tried in order with delays, for example a push notification immediately, SMS after a minute, and a voice call after five if the alert still isn't acknowledged.

Contact methods: each user can have at most 2 email addresses, 2 SMS numbers, and 2 phone numbers, plus any number of mobile app devices. A method has to be enabled before it receives notifications.

Two behaviors cause most surprises:

• First match wins: if an event has several rules, Opsgenie uses only the first rule whose conditions and time restrictions match. A broad rule above a specific one hides it.
• Free and Essentials are limited: custom notification rules aren't available on those plans, so each user gets one rule per event.

A working Opsgenie escalation setup in Terraform

If you manage Opsgenie with the official Terraform provider, an escalation policy with a repeat looks like this, based on the provider's documented example:

resource "opsgenie_escalation" "payments" {
  name          = "payments-escalation"
  owner_team_id = opsgenie_team.payments.id

  rules {
    condition   = "if-not-acked"
    notify_type = "default"
    delay       = 0

    recipient {
      type = "schedule"
      id   = opsgenie_schedule.payments_primary.id
    }
  }

  rules {
    condition   = "if-not-acked"
    notify_type = "default"
    delay       = 10

    recipient {
      type = "team"
      id   = opsgenie_team.payments.id
    }
  }

  repeat {
    wait_interval          = 10
    count                  = 2
    reset_recipient_states = false
    close_alert_after_all  = false
  }
}

Personal notification rules have their own resource, opsgenie_notification_rule, though most teams leave those to each engineer. Our Opsgenie reference guide covers the rest of the provider.

Common Opsgenie escalation mistakes

A routing rule that sends alerts nowhere: a team routing rule with "route to none" for a time window, often left over from a migration or a holiday, silently drops alerts during those hours.

Delays that assume they're sequential: if delays count from alert creation, as Atlassian's example suggests, a second rule with a 5-minute delay and a third with 5 minutes fire at the same time, not five minutes apart. A test alert settles it for your account.

"Not closed" with auto-close: a policy that escalates until closed and auto-closes after its repeats can mark a real incident as resolved with no one working it.

Notification rules nobody has checked: a new engineer with only the default rules, or someone whose phone number changed, is effectively not on call. Ask people to send themselves a test notification when they join a rotation.

Schedules with gaps: an escalation to "the on-call user of a schedule" notifies no one if the schedule has an uncovered hour. Check the schedule timeline for gaps after every rotation change.

Moving Opsgenie escalation policies and notification rules to another tool

With Opsgenie shutting down, every policy and rule has to be recreated somewhere. A few things to check, whatever the destination:

• Conditions: does the new tool distinguish "not acknowledged" from "not closed"? Many escalate only until acknowledged.
• Recipient types: "next user in schedule" and "random team member" may not exist. Decide on a replacement, usually a secondary schedule layer.
• Repeats: check whether repeats exist, how many are allowed, and whether there's an equivalent to reverting acknowledgement.
• Notification rules: these rarely migrate automatically because they're personal settings. Plan a short session where every on-call engineer sets up contact methods and sends a test page in the new tool.

Export your policies as JSON through the Escalation API before you start, so you have the exact delays and recipients to rebuild from. The rest of the sequence is in our Opsgenie migration checklist.

How FluidifyAI Regen handles Opsgenie escalation policies

FluidifyAI Regen models escalation as an ordered list of steps, each with its own timeout (minimum one minute) and a target: whoever is on call for a schedule, a specific named user, or a Slack channel. Acknowledging the incident stops escalation, and a policy can optionally repeat from the first step if every step passes without an acknowledgement. Policies fire when an incident matches a routing rule that references them, which plays the same role as Opsgenie's team routing rules. The details are in the Regen escalation docs.

Regen's Opsgenie importer reads your escalation policies through the Opsgenie API and recreates each one with the same name and description. Each Opsgenie rule becomes a step in the same order, with the delay converted to the step's timeout, and schedule and user recipients carried over. Here's what to check afterward:

• Team recipients are skipped: the importer logs a warning for each one, because Regen doesn't target teams in escalation steps. Replace them with a schedule or named users.
• Conditions and repeat settings aren't imported: Regen escalates until acknowledged, so rules that used "not closed" need a decision, and repeats need to be turned on by hand where you want them.
• Delay versus timeout: the importer copies each Opsgenie delay into the matching step's timeout, and Regen counts each timeout per step. If your Opsgenie delays were cumulative (5, 10, 15 minutes), the imported policy takes longer to reach later steps, so review the timings until the total time to the last step matches what you had.
• Notification rules stay with each person: personal Opsgenie notification rules aren't imported, so each engineer sets up their own notification preferences in Regen.

The importer has a dry-run mode that shows what it found before it writes anything, and the full move is in our Opsgenie-to-Regen walkthrough.

FAQ

What is an escalation policy in Opsgenie? It's an ordered set of rules that decides who is notified about an alert, after what delay, and under what condition (not acknowledged or not closed), with optional repeats.

What's the difference between escalation policies and notification rules in Opsgenie? Escalation policies belong to a team and decide who gets notified and when. Notification rules belong to each user and decide how that person is contacted, by push, SMS, voice, or email, and in what order.

How many times can an Opsgenie escalation repeat? Up to 20 times for a single alert, on plans that include repeats.

Why didn't my Opsgenie notification rule fire? Most often because an earlier rule for the same event matched first, a time restriction excluded the current time, or the contact method wasn't enabled. On Free and Essentials, custom rules aren't available at all.

Do Opsgenie escalation policies migrate to Jira Service Management? Atlassian's automated move transfers escalation policies to JSM. Check that your JSM tier supports the recipient types and repeats you use, since those are limited on JSM Standard.

Can I manage Opsgenie escalation policies with Terraform? Yes. The official provider has an opsgenie_escalation resource with rules, recipients, and repeat settings.

Get the policies on paper first

Before you change tools, export every escalation policy and ask each on-call engineer to screenshot their notification rules. It takes an afternoon, and it's the only complete record of how your team actually gets woken up. If you want to see how your policies would look in Regen, Regen is $100 a month flat with a free 30-day trial and its importer's dry run makes no changes.