Opsgenie
Opsgenie is Atlassian's on-call scheduling and alert-routing product: it takes a firehose of alerts from every monitoring tool a company runs, deduplicates and prioritizes them, works out which human should be paged right now according to a rotation and an escalation policy, and pushes a notification through whichever channel — push, SMS, voice call, email — actually reaches them. It does the same core job as PagerDuty, and the two are compared head to head at the end of this page. What makes Opsgenie the default pick on a specific class of team isn't a feature gap — it's that Atlassian owns Jira Service Management (incident tracking) and Confluence (postmortem documentation) too, and Opsgenie is the piece that was built to sit directly between an alert firing and those two tools picking up the story.
Imagine a school with a fire alarm, a phone tree to call parents, and a binder where the principal writes up what happened afterward. If all three of those things were made by different companies, someone has to manually copy information from the alarm log into the phone tree, and then again into the binder. Opsgenie is the alarm-and-phone-tree system made by the same company that also makes the sign-in sheet (Jira) and the binder (Confluence) — so when the alarm goes off, it can automatically start a new page in the binder and pre-fill who called whom and when, instead of someone typing all that up from memory the next morning.
What Opsgenie is and the problem it solves
☺ Like you're 10: It's the piece of software whose entire job is turning "something is broken" into "the right specific person's phone is now buzzing."
Opsgenie was founded in 2012 (headquartered between Istanbul and San Francisco) as a standalone alerting and on-call scheduling product, and Atlassian acquired it in 2018 for roughly $295 million — worth verifying the exact figure against contemporary reporting if it matters to you, but the acquisition itself is the fact that shapes everything else on this page. Since then Atlassian has progressively woven Opsgenie's on-call and alerting capabilities into Jira Service Management (JSM)'s "Operations" functionality at the higher plan tiers, while continuing to sell and support Opsgenie as a standalone product. Exactly how the two are packaged and priced has shifted more than once since the acquisition, so treat any specific tier name or bundling claim here as a snapshot — confirm current packaging on Atlassian's own pricing pages before you plan a migration around it.
Six objects cover almost everything you configure: an Alert is one incoming problem, deduplicated by a key called its alias; a Service groups the alerts that belong to one thing you operate (checkout, the payments API); a Team owns one or more services and has its own escalation policies, schedules, and routing rules; a Schedule defines whose turn it is right now via one or more Rotations; an Escalation policy is the ordered chain of who gets paged next, and after how long, if nobody acknowledges; and a Routing rule is the per-team logic that decides which escalation policy and schedule a given alert should actually use. Get comfortable naming these six precisely — nearly every Opsgenie question, in production or on an exam, is really a question about which of these six objects is misconfigured.
Every alert has an alias — a string you choose when you create it, not one Opsgenie invents for you. Two alerts sent with the same alias while the first is still open are treated as the same alert: Opsgenie adds a note to the existing one instead of paging again. Get the alias wrong — too specific (a fresh UUID every time) and you never deduplicate; too generic (one alias for a whole service) and unrelated problems collapse into a single alert — and every downstream behavior on this page, from notification volume to what a routing rule matches against, inherits the mistake.
Architecture: how one alert actually moves through the system
☺ Like you're 10: An alert comes in one door, gets sorted into the right team's mailbox by a rule, then works its way down a phone-call list until a real person answers.
Opsgenie is a fully hosted SaaS product — there is no self-hosted option and nothing you run yourself, the same structural shape as Datadog. Your job is producing alerts and configuring the routing on top of them; everything past ingestion is Atlassian's infrastructure. An alert's path through that infrastructure is a fixed pipeline worth memorizing end to end, because almost every failure mode below is one stage of it silently doing the wrong thing.
The configuration you actually write
☺ Like you're 10: Most of it lives in Terraform so a change to "who gets called at 3am" goes through a pull request, the same as any other production change.
Clicking a schedule together in the Opsgenie UI is fine for a five-person team's first week. Past that, the same discipline that governs infrastructure applies to on-call configuration: teams, schedules, escalations, and routing rules are managed as code, reviewed before merge, and applied by CI — using Atlassian's own opsgenie/opsgenie Terraform provider. Treat resource and argument names below as illustrative of the shape; confirm the exact schema against the provider's current registry docs before you ship, the same hedge multi-window burn-rate alerting gives for vendor-specific query syntax elsewhere on this site.
terraform {
required_providers {
opsgenie = { source = "opsgenie/opsgenie", version = "~> 0.6" }
}
}
provider "opsgenie" { api_key = var.opsgenie_api_key }
resource "opsgenie_team" "checkout" {
name = "checkout-oncall"
description = "Owns checkout availability and payment-flow alerts"
}
resource "opsgenie_schedule" "checkout_primary" {
name = "checkout-primary"
team_id = opsgenie_team.checkout.id
timezone = "America/New_York"
}
resource "opsgenie_schedule_rotation" "weekly" {
schedule_id = opsgenie_schedule.checkout_primary.id
name = "weekly-handoff"
start_date = "2026-01-05T09:00:00Z"
type = "weekly"
participant { type = "user", username = "alex@example.com" }
participant { type = "user", username = "sam@example.com" }
}
resource "opsgenie_escalation" "checkout" {
name = "checkout-escalation"
team_id = opsgenie_team.checkout.id
rules {
condition = "if-not-acked"
notify_type = "default" # the current schedule participant
delay = 0
}
rules {
condition = "if-not-acked"
notify_type = "default"
delay = 5 # minutes — matches the ack/engage defaults on
} # incident-management-and-on-call.html
rules {
condition = "if-not-acked"
notify_type = "user"
recipient = { type = "user", id = "team-lead@example.com" }
delay = 15
}
}
# routing rules are the piece worth reading twice: this is what actually
# decides which escalation policy an incoming alert ends up under
resource "opsgenie_team_routing_rule" "checkout_critical" {
team_id = opsgenie_team.checkout.id
name = "critical-prod-alerts"
criteria {
type = "match-all-conditions"
conditions {
field = "priority"
operation = "equals"
expected_value = "P1"
}
conditions {
field = "tags"
operation = "contains"
expected_value = "prod"
}
}
notify { type = "escalation", id = opsgenie_escalation.checkout.id }
}Everything above is the who and how. Alerts themselves come from an integration — Opsgenie ships several hundred, from a generic email/API integration to purpose-built ones for Prometheus Alertmanager, Datadog, CloudWatch, Zabbix, Nagios, and New Relic — each with its own API key used as a shared secret in the sending system's webhook config, not a per-user credential.
# the raw path underneath every integration: a plain REST call, auth'd with a
# GenieKey — this is exactly what Alertmanager's webhook_configs or a custom
# script sends under the hood
$ curl -s -X POST https://api.opsgenie.com/v2/alerts \
-H "Authorization: GenieKey $OPSGENIE_API_KEY" -H "Content-Type: application/json" \
-d '{
"message": "checkout p99 latency above 800ms",
"alias": "checkout-latency-p99",
"description": "Fired by the checkout-latency-slo burn-rate monitor",
"priority": "P1",
"tags": ["prod", "checkout"],
"responders": [{"type": "team", "name": "checkout-oncall"}]
}'
# acknowledge — stops further escalation rungs from firing
$ curl -s -X POST "https://api.opsgenie.com/v2/alerts/checkout-latency-p99/acknowledge?identifierType=alias" \
-H "Authorization: GenieKey $OPSGENIE_API_KEY"
# close — resolves it; a repeat POST with the SAME alias while it's still
# open just adds a note instead of paging again (the alias-dedup behavior above)
$ curl -s -X POST "https://api.opsgenie.com/v2/alerts/checkout-latency-p99/close?identifierType=alias" \
-H "Authorization: GenieKey $OPSGENIE_API_KEY"
# a heartbeat — Opsgenie's dead man's switch: if this ping doesn't arrive
# within the configured interval, Opsgenie raises an alert on YOUR behalf
$ curl -s -X GET "https://api.opsgenie.com/v2/heartbeats/nightly-backup-job/ping" \
-H "Authorization: GenieKey $OPSGENIE_API_KEY"Day-to-day workflows
☺ Like you're 10: Beyond writing the rules, most of the daily work is small human moves — snoozing a noisy alert, swapping a shift, and occasionally firing a fake alert on purpose to prove the whole chain still works.
Most engineers never touch the Terraform above day to day; they live in the mobile app or a ChatOps integration. Acknowledging, snoozing, adding a note, or escalating manually from a Slack message (/opsgenie ack checkout-latency-p99) covers the bulk of interaction during an active page. Swapping an on-call shift — someone's sick, a flight lands late — is an override: a temporary participant substitution on a schedule that reverts automatically at a set time, logged separately from the base rotation so "who was actually on call during the incident" stays answerable months later.
The habit worth stealing regardless of which paging tool a team uses: test the escalation, don't just describe it. Opsgenie's schedule and escalation views include a "who is on call right now" resolver and a test-alert path precisely so a team can fire a real alert into a real escalation policy on a quiet Tuesday afternoon and confirm every rung actually rings a phone, rather than discovering rung three has pointed at a departed employee's number during a real SEV1. The on-call readiness checklist on this course makes exactly this a mandatory pre-launch item, not an optional nice-to-have.
Gotchas and failure modes
☺ Like you're 10: Nearly every "why didn't anyone get paged" story turns out to be one of a handful of quiet misconfigurations, not the software being broken.
A routing rule with no match is a silent drop, not an error
Every team has a default catch-all rule, but a narrowly written custom rule — matching a specific tag or integration — that doesn't fire for an alert simply falls through to whatever the team's default routing does, which may not be the escalation policy anyone expects. There's no error, no bounce message, nothing in a log an on-call engineer is likely to be watching; the alert exists in Opsgenie, correctly, and nobody's phone rings. The fix is procedural: review routing rules whenever a new alert source or a new tag convention is introduced, and periodically audit that every rule a team relies on for a P1 has actually fired at least once in the last quarter — an idle rule is an unverified one.
Escalation policies exhaust
An escalation policy's rungs are finite. If every rung fires and nobody acknowledges — the whole team is unreachable, or a repeat count of zero means the chain simply stops after the last rung — the alert sits open, unacknowledged, un-escalated further, until someone happens to look. Set a repeat block that starts the chain over after the last rung, and route the truly last-resort rung to a team lead or a secondary team rather than letting the chain silently end at one person's phone.
Notification channels are not equally reliable, and quiet hours override real pages
Push notifications depend on the phone having signal and the app not being battery-optimized into silence by the OS; SMS delivery through a carrier can lag by minutes during a regional outage — precisely when a real incident is most likely to be carrier-adjacent infrastructure trouble too; and a per-user notification policy with quiet hours configured can suppress even a P1 push if it wasn't deliberately scoped to exclude high-priority alerts. The standard mitigation is layering channels — push, then SMS, then voice call, each a fixed number of minutes after the last, inside the user's own notification policy — rather than trusting a single channel to always land.
Anyone who has an integration's API key can create, update, or close alerts through it — Opsgenie has no way to distinguish "the real Alertmanager" from "someone who found the key in a leaked config file." Treat every integration key exactly like a database credential: store it in a secret manager, never commit it, and rotate it if a repository or CI log ever exposes it. A leaked key is a path to both fake pages (denial-of-service against your on-call team's attention) and silently closing real ones.
Heartbeats get disabled during a migration and never re-enabled
A heartbeat is Opsgenie's dead-man's-switch: something on your side is expected to ping it periodically, and Opsgenie raises an alert itself if the ping stops arriving. Teams reach for it to monitor a nightly batch job, a cron-based backup, or an integration's own health. The recurring failure mode is operational, not technical: someone disables a heartbeat during a migration or a maintenance window "temporarily," the migration finishes, and nobody remembers to turn monitoring back on — so the thing it was watching can now fail silently, forever, with the safety net still showing green in the UI because the heartbeat itself was never checking anything.
On a free Opsgenie trial org: create one team, one two-person schedule, and a three-rung escalation policy with 0/5/15-minute delays. Fire a real test alert at it and time how long each rung actually takes to notify — don't trust the configured numbers until you've watched a real phone buzz. Then deliberately break the alias: send two alerts with different aliases that describe the same underlying problem, and watch them show up as two separate pages instead of one deduplicated alert. That's the dedup gotcha, felt once, instead of read about.
Why it's the default in Atlassian-standardized shops
☺ Like you're 10: If your company already uses Jira for tickets and Confluence for docs, Opsgenie is the paging tool that was built to plug directly into both, instead of a separate tool you have to wire up yourself.
Opsgenie's native Jira Service Management integration can auto-create a linked Jira issue the moment an alert fires — carrying over the alert's description, priority, and tags — and, depending on configuration, sync status both directions: acknowledging in Opsgenie can move the linked issue's workflow state, and resolving the Jira issue can close the alert. For a team already running incident tracking through Jira, this removes the manual step of someone copy-pasting an alert's timeline into a ticket after the fact, and it means "how many P1s did we have this quarter" is one Jira query away rather than a cross-tool reconciliation exercise.
On the postmortem side, Opsgenie's action log — every acknowledgment, every note, every escalation rung that fired, with timestamps — is exactly the raw timeline a blameless postmortem needs to reconstruct what happened and when. Confluence ships a postmortem page template, and teams standardized on the Atlassian stack commonly seed a new Confluence page directly from that Opsgenie timeline rather than reconstructing it from memory and scattered Slack messages the next morning. None of this is a capability PagerDuty or Grafana OnCall lack outright — both integrate with Jira too — it's that Opsgenie, Jira, and Confluence share one vendor, one identity provider (Atlassian Access), one admin console, and one support relationship, which is precisely the kind of integration friction that's cheapest to avoid rather than solve.
That's also the honest limit of the argument: the case for Opsgenie is almost entirely about ecosystem fit, not a unique alerting capability. A team with no Atlassian footprint gains little by choosing Opsgenie over a comparably capable competitor, and a team deeply invested in Atlassian gains real, measurable friction reduction by choosing it — which is why "what does our incident-tracking and documentation stack already look like" is usually a faster way to this decision than a feature-by-feature bake-off.
Opsgenie vs. the alternatives
☺ Like you're 10: A few other tools do the same core job — the real differences are who made them, what they cost, and what else they're already wired into.
| Tool | Model | Best when | Costs you |
|---|---|---|---|
| Opsgenie | Atlassian-owned; native Jira Service Management & Confluence sync | Already standardized on Jira/Confluence for tracking and docs | The core case for choosing it is ecosystem fit, not a unique alerting feature; standalone packaging and pricing have shifted post-acquisition — verify current tiers |
| PagerDuty | Independent, long-standing market leader; broader incident-response workflow features beyond raw paging | Incident response itself — not just paging — is a first-class product need, or you're not on Atlassian tooling | A separate vendor relationship and identity layer from your ticketing/docs stack, if those live elsewhere |
| Grafana OnCall | Open-source core, tightly integrated with Grafana's alerting | Already standardized on Grafana for dashboards/alerting and want on-call in the same place, or want a self-hostable option | Smaller integration marketplace than Opsgenie or PagerDuty; less mature incident-workflow tooling |
| VictorOps (Splunk On-Call) | Splunk-owned; strongest when alert sources are already Splunk-centric | A Splunk-heavy observability stack where the same ecosystem-fit logic as Opsgenie applies, just for a different vendor | Smaller mindshare and community than PagerDuty or Opsgenie; same single-vendor-fit argument, narrower audience |
The underlying mechanisms on this page — alias-based deduplication, routing rules that select an escalation policy, escalation rungs with delays and repeats, on-call schedules with overrides, and a heartbeat as a dead-man's-switch — are close to universal across this whole product category, including PagerDuty. Learn the concepts here once and the vendor-specific UI is mostly a relabeling exercise; the concepts, not the click paths, are what alert design & alert fatigue and the SREF exam actually care about.
Pip the Hummingbird: The payments alert sat in Opsgenie for eleven minutes last night. Nobody's phone ever rang.
Nutty the Squirrel: I catalogued it an hour ago — the routing rule for that integration still points at the old fraud-team escalation. Nobody updated it when payments split off.
Foxy: Fine, it routed wrong — but why didn't the escalation at least exhaust and loop back to someone?
Pip the Hummingbird: Because the fraud team's policy has no repeat block. It rang two rungs, nobody answered at 2am, and the chain just... stopped. Correctly, by its own rules.
Timmy the Turtle: Has anyone actually fired a test alert through that routing rule since the split, or did we just assume it still pointed the right way?
Benny the Beaver: Never. It's in the Terraform, but nobody's re-run the escalation drill since we wrote it. I'll add a scheduled test-alert job — routing rules and escalation policies get the same "prove it, don't assume it" treatment as everything else we automate.
1. What does an alert's alias control, and what goes wrong if it's too specific or too generic? 2. Put these in the order an alert actually flows through: escalation policy, integration, notification channel, routing rule. 3. Why can a narrowly written routing rule fail silently instead of erroring? 4. What's the practical risk of an escalation policy with no repeat configured? 5. What specifically makes Opsgenie the default pick for a Jira/Confluence-standardized team, and what's the honest limit of that argument? 6. Name one thing an integration API key and a database credential have in common, operationally.
Check your answers
- The alias controls deduplication: two alerts sent with the same alias while the first is open are merged into one (a note is added, no new page). Too specific (unique every time) means duplicates never merge; too generic (shared across unrelated problems) means distinct incidents collapse into one alert.
- Integration (alert is created and deduped) → routing rule (matches conditions, picks a team/escalation) → escalation policy (steps through the on-call schedule, rung by rung) → notification channel (push/SMS/voice/email actually reaches the person).
- Because a non-matching custom rule simply falls through to the team's default routing rather than raising any error — there's no failed-delivery signal for an on-call engineer to notice, so the only defense is periodically auditing that every rule has actually fired recently.
- If every rung escalates and nobody acknowledges, the chain simply ends — the alert stays open, unescalated further, until someone happens to notice. A repeat block restarts the chain instead of letting it die silently.
- Opsgenie, Jira Service Management, and Confluence share one vendor, identity provider, admin console, and support relationship — an alert can auto-create a linked Jira issue and seed a Confluence postmortem from its own timeline. The honest limit: this is almost entirely an ecosystem-fit argument, not a unique alerting capability PagerDuty or Grafana OnCall categorically lack.
- Both are shared secrets rather than per-user logins: whoever holds the credential can act as the system it authenticates, so both belong in a secret manager, never in a committed config file, and both need rotation if ever exposed.