Werk #19767: Add Jira Service Management Operations notification plug-in
| Component | Notifications | ||||||
| Title | Add Jira Service Management Operations notification plug-in | ||||||
| Date | May 6, 2026 | ||||||
| Level | Prominent Change | ||||||
| Class | New Feature | ||||||
| Compatibility | Compatible - no manual interaction needed | ||||||
| Checkmk versions & editions |
|
Atlassian announced End-of-Support for the standalone Opsgenie product
on 2027-04-05. Tenants migrated to Jira Service Management Operations
can now use the new Jira Service Management Operations notification
method, which targets the Atlassian integration-events REST API at
api.atlassian.com/jsm/ops/integration/v2/.
Configuration only requires an integration API key obtained from the
JSM Operations integration template (e.g. the dedicated Checkmk
integration or a generic API integration). The plug-in does not need
the Atlassian Cloud ID, account email, or an API token because the
integration-events endpoint authenticates with the same
Authorization: GenieKey ... scheme as the legacy Opsgenie API.
The existing Opsgenie notification plug-in remains unchanged and will
continue to work against api.opsgenie.com until Atlassian's
End-of-Support date. After that date the Opsgenie plug-in will be
removed in a follow-up werk.
Behavior differences vs. the legacy Opsgenie plug-in:
- The configuration field for the alert owner is labeled "Assignee" to match what JSM Operations shows on the alert detail page.
- Responders can be configured directly in the rule. In addition to the existing "Responsible teams" list (team responders), the rule UI also accepts an "Additional responders" list with individual users (username/email), on-call schedules, and escalation policies. The integration's own team is still implicitly responsible.
- Flapping and downtime state changes are surfaced as additional notes on the alert because the integration-events endpoint does not expose the legacy tag-mutation calls.
- The JSM Ops alert alias is prefixed with the originating site name
(
<site>/HOST_PROBLEM_ID: <id>and<site>/SVC_PROBLEM_ID: <id>) so that problem-id counters from different sites in a distributed setup do not collide on JSM Ops alias deduplication. The site is taken from the notification context, i.e. it reflects the source site even when the notification is forwarded through a central site.