PagerDuty vs Jira Service Management: an SRE's field guide to every on-call concept
Overview
What each PagerDuty object becomes in Jira Service Management: events, dedup, escalation, phone paging, Slack, Terraform, rate limits and webhooks, checked against both APIs, both Terraform providers and Atlassian's bug tracker.
Opsgenie shuts down on 5 April 2027 and its alerting now lives inside Jira Service Management (Atlassian (opens in a new tab)). Our company is moving PagerDuty teams there too [reported], so we mapped every PagerDuty object an SRE touches to its JSM equivalent. Each cell comes from the vendor API references, the two Terraform providers (PagerDuty 3.37.0, atlassian-operations 2.1.0), Atlassian’s public bug tracker, or engineers reporting what broke.
Checked 7 November 2026.
Feature by feature
Data model
| Concept | PagerDuty | JSM | What bites |
|---|---|---|---|
| What pages people | Service, through its escalation policy | Team with Operations enabled, through its routing rules | In JSM, “Routing rules are not triggered if even one individual responder is specified in an alert” |
| Inbound signal | Event: POST events.pagerduty.com/v2/enqueue, 512 KB |
Alert: POST api.atlassian.com/jsm/ops/integration/v2/alerts, GenieKey auth, async 202 |
JSM alert message is capped at 130 characters |
| What you acknowledge | Incident. Alerts have “two only states: triggered and resolved” | Alert | One PagerDuty ack covers a group; JSM acks per alert |
| Incident record | Incident, up to 1,000 alerts | Jira work item, linked to alerts | JSM incidents use the Jira REST API, not the Ops API |
| Dedup key | dedup_key, 255 characters, per integration key |
alias, 512 characters, across integrations |
Same key from two integrations: PagerDuty keeps two alerts, JSM merges them |
| Severity | severity + urgency (high/low) + 5-level priority |
Priority P1–P5 only | No urgency; raising JSM priority restarts the notification flow |
| Custom data | Incident and service custom fields, incident types | Jira fields and work types; alert extra properties, 8,000 characters total | JSM’s List Alerts API doesn’t return extra properties (JSDCLOUD-17011 (opens in a new tab)) |
| Service catalog | Business and technical services, dependencies | Assets schemas (Software Registry, Business Portfolio), optional Compass sync | “Adding a service to an alert doesn’t change alert routing” in JSM |
Sources: PagerDuty alerts (opens in a new tab), send an alert event (opens in a new tab), event management (opens in a new tab); JSM alert notification flow (opens in a new tab), alert fields (opens in a new tab), alert priorities (opens in a new tab), services and incidents (opens in a new tab).
The biggest shift is the unit of work. In PagerDuty you acknowledge an incident and every alert grouped under it goes quiet. In JSM each alert is acknowledged on its own, and the Jira incident is a separate record that an automation rule has to create.
The dedup difference cuts both ways. PagerDuty ignores a dedup_key sent through a different integration key, so a check routed through two integrations pages twice. JSM merges the same alias whatever the source, and one ticket warns that “the team won’t realize the missing alert unless someone manually verifies” (JSDCLOUD-15956 (opens in a new tab)).
Routing and noise
| Concept | PagerDuty | JSM | What bites |
|---|---|---|---|
| Global routing | Event Orchestration: global → router → service | Global alert policies, then team routing rules (up to 100) | JSM has no router that picks a team from content; the team comes from the integration owner, a policy or the payload |
| Suppress | suppress: alert recorded, no incident. drop_event on global only |
Notification policy suppress; route to “No one”; integration ignore rule |
Both keep a record unless you drop or ignore |
| Hold a flapping alert | suspend N seconds: a resolve in time means no incident. Auto-pause: 2, 3, 5, 10 or 15 min |
Notification policy delay_action |
PagerDuty swallows the flap; JSM delays the page but the alert exists |
| Grouping | Time, content, intelligent or global; window 300–3,600 s | Rovo grouping: AI similarity, or rules with a window and group-by fields | From 3 December 2026, group actions such as “Ack all” spend Rovo credits; with extra usage off they are blocked until the 1st |
| Templating | Extraction with RE2 variables; cache variables (100 per orchestration, values kept 24 h) | Integration action rules with {{ field.extract(/re/) }} |
No cache variables in JSM |
| Auto-close | auto_resolve_timeout |
auto_close_action |
Equivalent |
| Re-page if still open | acknowledgement_timeout; escalation loops up to 9 |
auto_restart_action up to 20; escalation repeat up to 20 |
PagerDuty’s Terraform default for acknowledgement_timeout is 1800, so acknowledged incidents re-page after 30 minutes |
| Maintenance | Per service; integrations disabled | Per feature: policies, integrations, syncs | PagerDuty can’t resolve via the Events API during maintenance |
| Heartbeat | None built in. Documented workaround: cache variables + suspend + webhook, window up to 4 h | heartbeats with a ping endpoint |
JSM ping returns 202 even for a heartbeat that doesn’t exist, and needs a user API token (JSDCLOUD-18241 (opens in a new tab)) |
| Change context | Change Events API, kept 90 days; Recent Changes on the incident | Deployment tracking from Bitbucket, Jenkins, CircleCI, Octopus into change requests | JSM’s Ops API has no change-event ingest |
Sources: PagerDuty Event Orchestration (opens in a new tab), cache variables (opens in a new tab), orchestration examples (opens in a new tab), auto-pause (opens in a new tab), maintenance windows (opens in a new tab), change events (opens in a new tab); JSM routing rules (opens in a new tab), alert policies (opens in a new tab), alert grouping (opens in a new tab), integration actions (opens in a new tab), deployment tracking (opens in a new tab), JSM Ops REST spec (heartbeat ping).
Grouping on either side can hide the second problem. In PagerDuty, alerts that join an existing incident don’t page again, a behaviour Prometheus users have complained about since 2018 (alertmanager #1587 (opens in a new tab), 32 comments), and PagerDuty confirmed that Slack “does not send a new notification for each one” (PagerDuty Community (opens in a new tab)).
PagerDuty Community thread on grouped alerts in Slack, June 2025, captured 7 November 2026 at 07:10 UTC.
On-call
| Concept | PagerDuty | JSM | What bites |
|---|---|---|---|
| Schedule | Shift-based schedules (API v3, Terraform pagerduty_schedulev2); legacy ones can’t be created |
Schedule with base, override and final layers; rotations | Upgrading a PagerDuty schedule can’t be undone, and scripts on the v2 Schedules API stop working |
| Overrides | /v3/schedules/{id}/overrides; edit means delete and recreate |
/v1/schedules/{id}/overrides; “Take on-call” for one hour |
No Terraform resource on either side (PagerDuty #112 (opens in a new tab), open since 2019) |
| Escalation delay | Per level: each delay starts when the previous level fires | From when the escalation was added, normally alert creation | PagerDuty levels of 5 and 5 minutes become JSM rules at 0, 5 and 10 |
| Escalation targets | Up to 20 rules, 9 loops; round_robin or assign_to_everyone |
next, previous, all, random, users, admins; repeat up to 20 |
No round-robin in JSM (JSDCLOUD-13054 (opens in a new tab), 48 votes) |
| Business hours | Support hours switch urgency; low urgency never escalates | Time restrictions on routing rules | In JSM, routing straight to a schedule “no escalation takes place if the alert goes unacknowledged” |
| Handoff notice | Up to 48 h ahead; no SMS for new users since 10 December 2024 | schedule-start / schedule-end: just before, 15 min, 1 h or 1 day |
Fixed offsets in JSM |
Sources: PagerDuty shift-based schedule upgrade (opens in a new tab), escalation policies (opens in a new tab), round robin (opens in a new tab); JSM escalation policies (opens in a new tab), escalate an alert (opens in a new tab), overrides (opens in a new tab).
The escalation row is the one that silently changes paging after a migration. Atlassian’s own example has an alert created at 7:48 and rules firing at 7:48, 7:53 and 7:58: every delay counts from the start. Copy PagerDuty’s per-level numbers across and the third level fires earlier than it used to.
PagerDuty’s newer schedules are not settled in Terraform either. An open issue filed on 28 October 2026 reports that changing an active event in pagerduty_schedulev2 deletes it before creating the replacement, so a failed apply “leaves the schedule with nobody on call” (#1158 (opens in a new tab)).
Notifications
| Concept | PagerDuty | JSM | What bites |
|---|---|---|---|
| Contact methods | Phone, SMS, push, email, WhatsApp (falls back to SMS) | Voice, SMS, mobile, email | Adding an SMS or voice number in JSM “doesn’t create a default alert notification rule” |
| Per-user rules | By urgency, with a start delay | By action (create, ack, close, note, schedule start/end) and criteria; first match wins | No urgency split in JSM |
| Batching | Bundles open incidents; no published window | SMS every 1 minute, calls every 4 minutes | JSM skips the call if everything was acknowledged meanwhile |
| Act from a call | 4 acknowledge, 6 resolve, 8 escalate | 3 acknowledge, 2 close, 4 escalate, 6 ack all; call ends at 2 minutes | Different keys for the same muscle memory |
| Act from SMS | Reply codes ending in 4, 6 or 8; 14 and 16 act on all | ack 4421 |
JSM: “recipients can’t reply” when SMS comes from the “JSM” sender ID |
| Call a number to page | Live Call Routing, ring 15–60 s per responder; no API or Terraform | Incoming call routing | Both exist |
| Bypass Do Not Disturb | iOS critical alerts; Android DND and volume override; high urgency only | iOS critical alerts; quiet hours bypassed per alert with an OverwriteQuietHours tag |
No critical alerts on Android in JSM (JSDCLOUD-15997 (opens in a new tab), 63 votes) |
Sources: PagerDuty notification content and behaviour (opens in a new tab), SMS (opens in a new tab), mobile app settings (opens in a new tab), Live Call Routing (opens in a new tab); JSM SMS and voice (opens in a new tab), notification rules (opens in a new tab), notification preferences (opens in a new tab).
The phone is where engineers complain most. On JSM, the Opsgenie app’s long ringtone is gone: “all the sounds provided in JIRA Cloud are under 2-3 seconds”, and another admin wrote “I can see our on-call engineers missing critical notifications” (Atlassian Community (opens in a new tab), March 2025). Atlassian’s tracker has an open bug where a voice call is logged “no-answer” but never rang (JSDCLOUD-19207 (opens in a new tab), In Progress), and a request to lengthen the fixed call timeout for international numbers (JSDCLOUD-15759 (opens in a new tab), 58 votes). On PagerDuty, iOS users have asked since 2020 to set the critical-alert volume; one wrote in October 2025 that it was “so quiet I couldn’t even hear it from the next room” (PagerDuty Community (opens in a new tab)).
Reply in the PagerDuty Community thread on iOS critical-alert volume, opened in 2020, captured 7 November 2026 at 07:10 UTC.
Atlassian Community thread “Sounds for Alert notification”, captured 7 November 2026 at 07:10 UTC.
Incident response
| Concept | PagerDuty | JSM | What bites |
|---|---|---|---|
| Automation | Incident workflows; triggers on type, condition, manual or API | Jira Automation with alert triggers | Opsgenie actions and incident rules are not migrated; they must be rebuilt |
| Roles | Incident Commander, Customer Liaison, up to 10 custom; no REST API, webhook incident.role.assigned |
None. Assignee and Responders field | Opsgenie responder roles are not migrated |
| Conference bridge | Bridge field on the incident; workflow actions for Zoom, Google Meet, Teams | Built-in conference calls (50 people), Zoom, Teams | Both work; JSM’s needs no third party |
| Slack | /pd (/pdeu in EU), dedicated incident channels |
/jsmops, incident channels |
JSM doesn’t update the Slack message on acknowledge (JSDCLOUD-18368 (opens in a new tab), 28 votes) |
| Microsoft Teams | Standard channels only; dedicated incident chats | Standard channels only; incident chats and meetings | Neither supports private channels |
| Run scripts in your network | Automation Actions and runner, outbound HTTPS | Jira Edge Connector, polls a queue, outbound only | JSM’s JEC API is marked Experimental |
| Status pages | Status updates; pages are read-only in the API | Status pages in Operations; API Experimental | Neither manages pages in Terraform |
| Post-incident review | /incidents/{id}/review, one per incident |
PIR work item, exportable to Confluence | JSM’s PIR template can’t be changed (JSDCLOUD-12167 (opens in a new tab), 77 votes) |
| MTTA/MTTR | /analytics/... API, data within about 24 h |
Reports in the UI; no reports API | No programmatic MTTA in JSM Ops |
Sources: PagerDuty incident workflows (opens in a new tab), incident roles (opens in a new tab), conference bridge (opens in a new tab), Slack user guide (opens in a new tab), Microsoft Teams (opens in a new tab), Automation Actions (opens in a new tab), post-incident reviews (opens in a new tab); JSM shift from Opsgenie (opens in a new tab), incident responders (opens in a new tab), conference calls (opens in a new tab), Slack (opens in a new tab), Microsoft Teams (opens in a new tab), Jira Edge Connector (opens in a new tab), PIR (opens in a new tab).
Migrated integrations are where teams lose pages. One admin reported that “after migrating from Opsgenie to JSM Operations, all Zabbix integrations for all teams stopped working” and had to move to the Edge Connector (Atlassian Community (opens in a new tab), December 2025). Alertmanager is the easy case: its Opsgenie receiver works against JSM by changing api_url (alertmanager #4244 (opens in a new tab)).
Atlassian Community question, captured 7 November 2026 at 07:10 UTC.
APIs and code
| Concept | PagerDuty | JSM | What bites |
|---|---|---|---|
| Event intake limit | About 120 calls/min per integration key, plus account limits; a 429 event is not ingested |
Not published; buckets per site and request type, per Atlassian’s tracker | One JSM integration in a storm shares the site’s budget (JSDCLOUD-18905 (opens in a new tab)) [inferred] |
| Management API | REST v2, 960 requests/min per key, user or app, with rate-limit headers | /jsm/ops/api/{cloudId}/v1/...; no incidents, services or reports endpoints |
JSM incidents need a second API |
| Outbound events | Webhooks v3: 2xx within 5 s, retries for 48 h, disabled 24 h after 3 drops | Webhook integration; description truncated to 1,000 characters | JSM documents no retry behaviour |
| Terraform | 51 resources; missing overrides, status pages, roles, Teams | 16 resources; missing overrides, syncs, status pages, grouping, chat | See below |
| CLI | None official; go-pagerduty ships pd, last release January 2024 |
None | Both are API and Terraform |
| Regions | US and EU, separate API hosts | 11 data residency locations; the service registry is not pinned | Moving JSM’s region takes alerting offline for up to 24 h |
Sources: PagerDuty Events API rate limits (opens in a new tab), REST rate limits (opens in a new tab), webhook behaviour (opens in a new tab), service regions (opens in a new tab), provider (opens in a new tab); JSM REST API (opens in a new tab), webhook integration (opens in a new tab), provider (opens in a new tab), Opsgenie data residency (opens in a new tab).
Terraform on both sides has rough edges an SRE will hit in a first week. PagerDuty’s Event Orchestration router is one resource holding every rule, so per-service modules can’t add their own routes (#648 (opens in a new tab), 26 reactions). On JSM, the services API began rejecting the team-ID format its own docs describe; one team saw “85 services failing” out of 93 “on an apply where every single HTTP call had returned 2xx” (PR #103 (opens in a new tab), open). The JSM provider’s GitHub repository has issues disabled; bugs go to Atlassian’s tracker.
Before you commit
When the pager itself fails
| Concept | PagerDuty | JSM |
|---|---|---|
| Failure domain | Its own multi-region AWS footprint | The same Atlassian Cloud site as Jira and Confluence |
| Recent incident | 28 August 2025: ~95% of events rejected with 502 for 38 min; 23% of notifications delayed 5+ min; status page silent for two hours (postmortem (opens in a new tab)) |
10–11 September 2025, about 25 hours of degradation in the US region; alerts kept “notifying users, but without the intended content” (status (opens in a new tab)) |
| Upstream outage | — | 20–21 October 2025: “Atlassian Cloud Services impacted” by the AWS outage, 07:56 to 05:24 UTC (status (opens in a new tab)) |
Neither tool can tell you it has stopped paging. Keep a check outside both that alerts through another channel.
Before the cutover
- Recalculate every escalation delay from alert creation, not per level.
- Decide what replaces urgency, and check that every responder has a notification rule for their phone number.
- Rebuild PagerDuty workflows and Opsgenie actions as Jira Automation, and test each integration end to end; migrated ones can stop silently.
- Make dedup keys unique per source, since JSM merges an alias across integrations.
- Watch every sender for
429after cutover; JSM gives no usage dashboard.
Sources
- Atlassian, “The evolution of IT operations” (Opsgenie end of sale 4 June 2025, shutdown 5 April 2027). https://www.atlassian.com/blog/company-news/evolution-of-it-operations (opens in a new tab)
- PagerDuty documentation, docs.pagerduty.com, read 7 November 2026; pages linked under each table.
- Atlassian Support, Jira Service Management Cloud documentation, read 7 November 2026; pages linked under each table.
- Atlassian, JSM Operations REST API reference and OpenAPI spec. https://developer.atlassian.com/cloud/jira/service-desk-ops/rest/v2/intro/ (opens in a new tab)
- PagerDuty/terraform-provider-pagerduty v3.37.0 (26 October 2026) and issues #112, #648, #1158. https://github.com/PagerDuty/terraform-provider-pagerduty (opens in a new tab)
- atlassian/terraform-provider-atlassian-operations v2.1.0 (5 November 2026) and PR #103. https://github.com/atlassian/terraform-provider-atlassian-operations (opens in a new tab)
- Atlassian public tracker, JSDCLOUD-12167, -13054, -15759, -15956, -15997, -17011, -18241, -18368, -18905, -19207; votes read 7 November 2026. https://jira.atlassian.com/projects/JSDCLOUD (opens in a new tab)
- Prometheus Alertmanager issues #1587 and #4244. https://github.com/prometheus/alertmanager/issues/1587 (opens in a new tab) ; https://github.com/prometheus/alertmanager/issues/4244 (opens in a new tab)
- PagerDuty Community threads on grouped-alert Slack notifications and iOS critical-alert volume; Atlassian Community threads on Jira app alert sounds and Zabbix after migration. Linked inline.
- PagerDuty Engineering, “August 28 Kafka Outages”, 4 September 2025. https://www.pagerduty.com/eng/august-28-kafka-outages-what-happened-and-how-were-improving/ (opens in a new tab)
- Opsgenie Statuspage incidents mptwfv1cg7ls (10–11 September 2025) and y1j42zwxgm26 (20–21 October 2025). https://opsgenie.status.atlassian.com/ (opens in a new tab)
