Send alerts to Jira Service Management

A Jira Service Management channel sends each Pingstack incident to a team in Jira Service Management Operations as an alert. Your schedules, routing rules and escalation policies there decide who is paged. Teams moving from Opsgenie can use this channel once they have moved to Jira Service Management. Jira Service Management channels are available on plans that include incident-management integrations; other plans show Available on Team with an Upgrade link. An Editor or Admin can create and change the channel.

Prerequisites

• A team with operations turned on in Jira Service Management. If the team’s details show Connect JSM operations, connect operations first.
• An API integration on that team: open the team’s operations page, choose Integrations, then Add integration, select API, name it and choose Continue.
• The integration turned on with Turn on integration. Jira Service Management drops requests sent to an integration that is turned off.
• The integration’s API key.

Create the channel

1. Open Notification channels and choose Add a channel, or choose Add destination on the Jira Service Management card.
2. Select Jira Service Management, paste the key into API key and choose the notification group.
3. Under Priority, choose a priority for When a check is down, When a check is late and When a check is degraded.
4. Save, open the channel and choose Send test alert.
5. Assign the notification group to the checks that should page through Jira Service Management.

Expected result: Pingstack shows “Test alert sent to Jira Service Management, then resolved.” The team’s alerts include a closed Test alert from Pingstack at P5. Include closed alerts in your alert view to see it.

Jira Service Management processes requests after accepting them. The test alert waits for its result, so a problem such as a turned-off integration is reported in the message, for example “Jira Service Management didn’t accept the test alert: processing failed: Integration is disabled.”

After saving, Pingstack shows the key only as its last four characters. Leave the field blank when editing to keep the saved key, or enter a new key to replace it.

How incidents map to alerts

Pingstack event	Jira Service Management result
An incident opens	A new alert at the channel’s priority for the check’s status
The check’s status changes while the incident is open	A note on the same alert, for example “Priority is now P3.”
The check recovers	The alert closes

Jira Service Management can’t change an open alert’s priority, so the alert keeps the priority it opened with and later changes are added as notes. All requests for one Pingstack incident use the same alert alias. Pingstack checks whether the incident has already recovered before each send, so a delayed retry closes the alert instead of reopening it.

New alerts include a message of up to 130 characters, a description with the cause and a link to the check, and details for the check name, status, cause, start time and check link.

Priority

Check status	Default priority
Down	P1
Late	P2
Degraded	P3

You can choose any priority from P1 to P5 for each status.

Delivery failures

Jira Service Management rejecting the key or the request is not retried. Rate limits and outages are retried automatically with increasing delays.

Because Jira Service Management accepts requests before processing them, Pingstack checks each incident alert’s result shortly after sending. If Jira Service Management couldn’t process it, the delivery is marked Failed with its reason in the channel’s recent deliveries and in notification history.

Plan changes

If the account moves to a plan without incident-management integrations, existing Jira Service Management channels keep their keys but show Paused and send nothing. Moving back to an eligible plan resumes delivery.