Opsgenie

Opsgenie is Atlassian's incident-alerting and on-call product: it does not monitor anything itself, but every monitoring tool a team already runs — Prometheus, Datadog, CloudWatch, a health-check script, a support inbox — can hand it a raw signal, and Opsgenie is the layer that decides whether that signal wakes a human up, who that human is right now, and what happens if they don't answer. Founded in 2012 and acquired by Atlassian in 2018 (reportedly for around $295 million — verify the figure if you need it precisely; this page treats it as background, not as a number worth memorizing), Opsgenie's defining trait today is less about its alerting engine, which is genuinely comparable to PagerDuty's, and more about where it sits: bundled into the same company that sells Jira, Jira Service Management, Confluence, and Statuspage, which turns "which paging tool should we buy" into a question that's frequently answered by procurement and existing licensing before a single feature gets compared. This page covers the alerting architecture, the four-noun model that actually routes a page, schedules and overrides, the API and Terraform config you'd really write, the Atlassian-ecosystem integration story specifically, and the gotchas — then closes with the honest version of the Opsgenie-vs-PagerDuty decision.

What Opsgenie is and the problem it solves

☺ Like you're 10: It doesn't watch your systems — it's the thing that turns "something's wrong" from a dashboard into an actual phone ringing, on the right phone, in the right order.

Before a dedicated alerting layer existed, teams wired monitoring tools directly to notification channels — a Nagios check that emails a distribution list, a cron job that posts to a Slack channel — and every one of those wires encoded its own, usually undocumented, idea of who should respond and how urgently. Nobody could answer "who's on-call right now" without opening a spreadsheet, and a monitoring tool that could email had no concept of "wait ten minutes, then try someone else." Opsgenie's job is to be the single answer to both questions: one place that knows the current on-call roster for every team, and one engine that knows what to do when the first attempt goes unanswered — independent of which monitoring tool raised the original signal.

That independence is the core design choice worth naming up front. Opsgenie is deliberately a routing and notification layer, not a monitoring product — it has no agent that watches CPU or a synthetic check that pings your homepage. Every alert arrives from somewhere else, through one of 200-plus integrations or a plain REST call, and Opsgenie's entire value is what happens in the seconds and minutes after that alert lands: dedup it against alerts already open, route it to the right team, and escalate it through a chain of humans until someone acknowledges it. That's also why Opsgenie shows up as a cross-reference on nearly every other alerting-adjacent page in this course rather than as a monitoring source in its own right — see monitoring & observability for where the signals Opsgenie routes actually come from, and incident management for the primary/secondary/escalation-policy vocabulary this page builds directly on top of.

Where it fits: the Atlassian ecosystem and the Jira Service Management story

☺ Like you're 10: Opsgenie doesn't live alone — it's one piece of the same toolbox as Jira and Confluence, and the company that makes it keeps stitching the pieces closer together.

Atlassian's 2018 acquisition of Opsgenie slotted it into a product line that already owned the ticket (Jira Service Management, renamed from Jira Service Desk in 2020), the wiki (Confluence), and — after a 2019 acquisition of its own — the public status page (Statuspage). The integration story that follows from that ownership is the single biggest reason this page exists as a separate consideration from PagerDuty, so it's worth walking through concretely rather than waving at "they integrate."

Jira Service Management: alerts that become tickets, automatically

The core wire is bidirectional. An Opsgenie integration for Jira Service Management can auto-create a linked Jira issue the moment an alert opens — carrying the alert's priority, tags, and responders across as issue fields — and status changes then sync in both directions: acknowledging or closing the alert in Opsgenie updates the linked issue's status, and (configurable) resolving the Jira issue can close the alert back in Opsgenie. For a team already running its ticket queue in Jira, that means an incident's operational timeline (who got paged, when they acked) and its record-keeping trail (the ticket a manager or auditor actually looks at later) live in two systems that stay honestly in sync, instead of someone manually copying alert history into a ticket after the fact.

Statuspage, Confluence, and the direction Atlassian has been consolidating in

Two more Atlassian products round out the loop. An Opsgenie incident can trigger a Statuspage update automatically, so the external-facing status page a customer checks during an outage reflects the internal incident's state without someone manually toggling it mid-fire. And a resolved incident's timeline exports cleanly into Confluence as the starting draft of a postmortem, feeding directly into the blameless-postmortem practice this course covers in culture & collaboration. Treat one more thing here as directional rather than fixed: Atlassian has, over the past several product cycles, been folding Opsgenie's on-call scheduling and alerting capability directly into Jira Service Management's own "Operations" / incident-management surface for JSM's higher tiers, rather than keeping the two products' feature sets strictly separate forever. Exactly which capabilities live natively in JSM versus require the standalone Opsgenie product — and under which JSM plan — has shifted before and is worth checking against Atlassian's current documentation rather than assuming this page's snapshot is still accurate by the time you're evaluating it.

Architecture: the alert lifecycle and the four nouns that route it

☺ Like you're 10: Four different settings decide what happens to an alert, and mixing them up is the single most common way to misconfigure the whole system.

The alert lifecycle and where signals come in

Every Opsgenie alert moves through the same three states: Open (just arrived, unacknowledged), Acknowledged (a human has claimed it and stopped the escalation clock), and Closed (resolved, either by a human or automatically when the source system reports recovery). A fourth state, Snoozed, pauses notifications for a set window without closing the alert — the right move for "I've seen this, I'm working it, stop paging me about it for twenty minutes" without pretending it's actually resolved. Alerts arrive through one of roughly 200 built-in integrations (Prometheus/Alertmanager, Datadog, New Relic, AWS CloudWatch, Zabbix, Jira, and dozens more), a generic email integration (every integration gets its own inbound email address), or the plain REST API — and every integration, regardless of source, produces the same shape of object internally, which is what lets one escalation and notification model handle alerts from completely unrelated tools identically.

The four nouns: alert policy, notification policy, escalation, and personal rules

Almost every Opsgenie misconfiguration traces back to confusing these four. An alert policy is team-scoped pre-processing that runs the instant an alert arrives — it can add tags, re-route to a different team, deduplicate against an already-open alert with a matching key, or suppress the alert entirely before a human is ever involved. A notification policy is also team-scoped, but it governs when the team as a whole gets bothered at all — the classic use is muting non-critical alerts outside business hours, or auto-closing an alert that's been open unacknowledged past a threshold that suggests it's stale. An escalation (escalation policy) is the ordered chain of who gets tried and in what order if the first attempt goes unanswered — "notify the on-call schedule now; if unacknowledged after 10 minutes, notify the secondary; if unacknowledged after 20, notify the team lead directly." And a notification rule is personal: every individual user configures, in their own profile, which channel to use and how fast — "for P1 alerts, call my phone immediately; for P3, email me, no rush." Escalation decides who's up; notification rules decide how that specific person gets bothered once they are.

Schedules, rotations, and overrides — the on-call calendar

☺ Like you're 10: The base calendar says who's on this week; an override is a sticky note on top of it for the one week that's different, and nobody has to redraw the whole calendar to add one.

A schedule belongs to a team and is made up of one or more rotations — each rotation defines a participant list, a rotation type (daily, weekly, or a custom interval), a start time, and optionally a time restriction (say, only counting as "on-call" during business hours, with a separate night rotation covering the rest). Layering rotations is how a team builds something like "primary rotates weekly among six engineers, but only 9-to-5; a separate always-on night rotation among three people covers the rest," inside one schedule object rather than two disconnected calendars someone has to keep in sync by hand.

An override sits on top of a rotation without editing it: it's a time-boxed substitution — "Priya covers Tuesday through Thursday instead of Sam" — that Opsgenie resolves for exactly that window and then automatically stops applying, leaving the underlying rotation pattern untouched for every week after it. That's the mechanism this course's on-call culture page leans on directly when it argues that swap and opt-out mechanisms need to be genuinely self-serve: an engineer covering a colleague's shift for a dentist appointment shouldn't need anyone to touch the rotation's actual configuration, and the override's automatic expiry means nobody has to remember to change it back either.

The API call every team eventually scripts against is who's on-call right now — resolving a schedule to the actual current participant, accounting for any active override, without a human opening the calendar UI:

# GenieKey auth is used consistently across the REST API — see the config section below
$ curl -s -H "Authorization: GenieKey ${OPSGENIE_API_KEY}" \
    "https://api.opsgenie.com/v2/schedules/checkout-primary/on-calls?scheduleIdentifierType=name"
# → returns the resolved on-call participant(s) for right now, override included

Configuration as code and the API you actually touch

☺ Like you're 10: Instead of clicking through screens to set up who's on-call, you write it down in files, so the schedule is reviewed and versioned the same way the code it's protecting is.

Opsgenie has an unofficial, community-maintained Terraform provider (opsgenie/opsgenie on the Terraform Registry) that covers the objects this page has already introduced — teams, schedules, rotations, escalations, and integrations — as ordinary managed resources. It is not maintained with the same first-party guarantee as, say, the AWS or Kubernetes providers, so check its current maintenance status on the registry before betting production configuration on it rather than assuming it from this page.

resource "opsgenie_team" "checkout" {
  name = "checkout-oncall"
}

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-primary"
  start_date  = "2026-01-05T09:00:00Z"
  type        = "weekly"
  participants {
    type = "user"
    id   = "user-id-priya"
  }
  participants {
    type = "user"
    id   = "user-id-sam"
  }
}

resource "opsgenie_escalation" "checkout" {
  name    = "checkout-escalation"
  team_id = opsgenie_team.checkout.id
  rules {
    condition   = "if-not-acked"
    notify_type = "default"
    delay       = 10   # minutes before this rule fires
    recipient {
      type = "schedule"
      id   = opsgenie_schedule.checkout_primary.id
    }
  }
  rules {
    condition   = "if-not-acked"
    notify_type = "default"
    delay       = 20
    recipient {
      type = "user"
      id   = "user-id-team-lead"
    }
  }
}

The REST API is what nearly every integration and every automation actually calls underneath, and it's worth knowing the shape directly rather than only through a UI or a provider. Every call authenticates with a GenieKey — an API-key scheme, not a bearer token — scoped per integration, so a leaked key from one integration doesn't hand over the whole account; keep those keys out of committed files the same way Secrets & Credential Management argues for any other credential.

# create an alert — the call nearly every custom integration ends up wrapping
$ curl -s -X POST "https://api.opsgenie.com/v2/alerts" \
    -H "Authorization: GenieKey ${OPSGENIE_API_KEY}" \
    -H "Content-Type: application/json" \
    -d '{
      "message": "Checkout error rate above burn threshold",
      "priority": "P2",
      "responders": [{ "type": "team", "name": "checkout-oncall" }],
      "tags": ["service:checkout", "env:prod"],
      "alias": "checkout-error-rate-burn"
    }'

# a heartbeat — the dead-man's-switch pattern: if this ping stops arriving,
# Opsgenie itself raises the alert, which catches "the monitoring system died" too
$ curl -s -X GET "https://api.opsgenie.com/v2/heartbeats/checkout-cron/ping" \
    -H "Authorization: GenieKey ${OPSGENIE_API_KEY}"

Most teams never hand-write the first call above, because Prometheus's Alertmanager ships a native Opsgenie receiver — the config that actually connects a self-hosted alerting stack to Opsgenie's escalation engine in production:

# alertmanager.yml
receivers:
  - name: opsgenie-checkout
    opsgenie_configs:
      - api_key: ${OPSGENIE_API_KEY}
        message: '{{ .CommonAnnotations.summary }}'
        description: '{{ .CommonAnnotations.description }}'
        priority: '{{ if eq .CommonLabels.severity "critical" }}P1{{ else }}P3{{ end }}'
        responders:
          - type: team
            name: checkout-oncall
        tags: 'service:checkout,env:prod'

Day-to-day operations

☺ Like you're 10: Once a page fires, there are really only five things anyone does about it — claim it, quiet it, close it, hand it up, or leave a note for whoever's next.

The actions a responder actually takes, whether from the mobile app, the web UI, or scripted through the API, are the same handful every time: acknowledge (claim it, stop the escalation clock), snooze (quiet it for a set window without closing it), close (it's resolved), escalate (manually push it to the next rule early, without waiting out the delay), and add a note (leave context for whoever looks at this alert next — the raw material a postmortem gets built from later). Alongside the alerting path, maintenance mode mutes a service's alerts for a defined window — the same deploy-aware suppression this course's on-call culture page argues should be a pipeline step rather than a habit: a CI/CD stage opens it automatically the moment a deployment starts and closes it once the canary bake completes, so a rollout's expected noise never has to be manually remembered by whoever's on-call that week.

Gotchas and failure modes

☺ Like you're 10: A few defaults that feel harmless on day one — a missed heartbeat, a free-tier limit, an unread migration notice — turn into a real gap in coverage later.

A missed heartbeat is itself the incident. The heartbeat pattern above is a dead man's switch specifically because it inverts the usual logic: instead of alerting when something bad happens, it alerts when the expected "I'm fine" signal stops arriving, which is what catches "the monitoring system itself crashed" — a failure mode a normal alert, dependent on that same monitoring system, can never report on its own. Forgetting to configure a heartbeat's expected interval correctly is a common reason teams find out about a dead cron job or a dead exporter days late, from a person noticing rather than from Opsgenie.

Tier gating on Incident features. Plain alerting — integrations, escalations, schedules — is available broadly, but Opsgenie's higher-level Incident object (grouping multiple related alerts under one incident record, with its own timeline and stakeholder updates) has historically been gated to Standard and Enterprise plans rather than the Free or Essentials tiers. Treat any specific tier name or limit here as something to re-verify on Atlassian's current pricing page — these move — but budget for the fact that "incident management," as a named feature separate from plain alerting, is usually a paid-tier decision, not a given.

The Edge Connector, for private-network integrations. For monitoring systems that live inside a network Opsgenie can't reach — no inbound path, no exposed webhook endpoint — Opsgenie offers an Edge Connector: a small process you run inside that network which polls Opsgenie outbound-only and executes the resulting action locally. It's the same dial-out posture this course keeps running into on tool pages that have to operate across a firewall boundary — Jenkins agents and the Datadog Agent both default to the identical "only I ever initiate the connection" shape, for the identical reason: nothing has to poke a hole inbound into a network you don't want exposed.

The JSM consolidation is a moving target. Because Atlassian has been actively folding Opsgenie capability into Jira Service Management's own tiers, a setup guide or blog post from a couple of product cycles ago may describe a feature split that's since shifted — a capability that once required the standalone Opsgenie product might now be native to a JSM plan, or vice versa. Confirm against Atlassian's current documentation before designing a rollout around where a specific feature lives today.

Data residency. Opsgenie, like most Atlassian cloud products, offers separate US and EU hosting regions, and which one an organization's data lives in is set at account creation and isn't a casual later change. For regulated environments this belongs in the same conversation as any other vendor's data-residency commitments — worth confirming explicitly during procurement, not assumed.

Opsgenie vs. PagerDuty (and the rest): choosing on ecosystem, not feature parity

☺ Like you're 10: Two tools that both do the phone-tree job almost identically well — so the real decision usually comes down to which company you're already paying, not which one has a better feature.

Here's the uncomfortable truth worth saying plainly: at the level of alert routing, escalation policies, schedules, overrides, and multi-channel notification, Opsgenie and PagerDuty do the same job to a very similar standard. Both support the four-noun model this page walked through (under different exact names), both have mature mobile apps, both integrate with the same couple hundred monitoring tools, and both have REST APIs and Terraform coverage. Teams that run detailed side-by-side bake-offs between the two frequently conclude the feature gap is real but narrow — and then the decision gets made on a different axis entirely.

The practical rule, stated as plainly as the table above implies: if the organization is already a committed Jira and Jira Service Management shop, evaluate Opsgenie first and require a specific, named reason to look elsewhere — the integration depth and single-vendor procurement argument is real and it compounds over years, not just at rollout. If there's no existing Atlassian commitment, the decision genuinely opens up, and PagerDuty's reputation as the category's longest-standing specialist, or Grafana OnCall's fit with an already-Prometheus-native stack, become entirely legitimate starting points instead of a fallback. Either way, the concepts on this page — alert policy versus notification policy versus escalation versus personal rules, schedules versus overrides, dead-man's-switch heartbeats — transfer almost directly to whichever vendor a team lands on, which is exactly why this course teaches incident management and on-call culture vendor-neutrally before either tool page. Practice the whole loop hands-on in Capstone Part 5 — Incident Response, or go tune a noisy rotation directly in Drill — Set Up Meaningful Alerts.