Jira Service Management (Opsgenie) integration

The Jira Service Management (Opsgenie) integration creates an alert through the Alerts API of Jira Service Management, or of Opsgenie, when a monitor goes down and closes that same alert when the monitor recovers. Pairing is done through the alert alias, which Site Qwality derives from the monitor and the outage. In the API and in channel details the type is still called opsgenie.

What you need

An API key from an API integration.

In Jira Service Management, go to Operations → Integrations. Still on Opsgenie: Settings → Integrations.
Add an API integration.
Copy its API key.

Endpoint

The same alerts live on three hosts, and a key only works on its own:

`endpoint`	In the dashboard	Sends to
`jsm`	Jira Service Management	`api.atlassian.com/jsm/ops/integration/v2/alerts`
`opsgenie_us`	Opsgenie (US)	`api.opsgenie.com/v2/alerts`
`opsgenie_eu`	Opsgenie (EU)	`api.eu.opsgenie.com/v2/alerts`

The dashboard picks Jira Service Management unless you choose otherwise. Atlassian stops Opsgenie on 5 April 2027, and the Opsgenie choices go away then. A key sent to the wrong host is refused and recorded as rejected.

The endpoint is set when you add the integration. To change it, add the integration again with the other endpoint and move your channels to it. An integration with external_ref: null sends to Opsgenie US.

Connect it

In the dashboard, go to Manage → Integrations and click the Jira Service Management (Opsgenie) card. Name it, choose the Endpoint, paste the key into API Key, and click Add integration.

Or through the API, with POST /integration/opsgenie:

curl -X POST https://api.siteqwality.com/integration/opsgenie \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "friendly_name": "Acme JSM",
    "api_key": "<api-integration-key>",
    "endpoint": "jsm"
  }'

Field	Required	Description
`friendly_name`	yes	Up to 256 characters.
`api_key`	yes	The API integration’s key.
`endpoint`	no	`jsm`, `opsgenie_us` or `opsgenie_eu`. Omitted means `opsgenie_us`, so Jira Service Management customers must send `"jsm"`.

The key is not verified at save time. It never reads back in full; the endpoint reads back as external_ref.endpoint.

Add it to a notification group

Right after you add the integration, the dashboard offers to do this for you: choose a group or create one, choose which monitors alert that group (the ones that already do, every monitor, or ones you pick), then send a test. If you skipped it, Route alerts on the integration’s card opens the same step. To do it by hand:

Go to Respond → Notifications. Click a group’s name to open it, or click Add group to make a new one.
Under Notifications, click Add notification method. Set Notification type to Jira Service Management (Opsgenie) and choose this integration under Integration.
Click Done editing, then Save changes (Create group for a new group).

Through the API, create the channel with POST /notification:

curl -X POST https://api.siteqwality.com/notification \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "notification_group_id": "<your-group-id>",
    "type": "opsgenie",
    "details": { "opsgenie_integration_id": "<opsgenie-integration-id>" }
  }'

Create and close

Down and up events share one alias built from the monitor ID and the ID of the state transition that opened:

sq-http-<monitor-id>-<state-transition-id>
sq-browser-<browser-check-id>-<state-transition-id>

Monitor goes down → POST .../v2/alerts on the integration’s endpoint, with message: "Monitor DOWN: <name>", a description carrying the URL and failure reason, and that alias.
Monitor recovers → POST .../v2/alerts/<alias>/close?identifierType=alias, with the recovery message attached as the close note.

Open alerts are deduplicated by alias, so repeated failures within one outage update a single alert rather than stacking. A separate outage later produces a different state transition, and therefore a new alert.

Alert messages longer than 130 characters are truncated to fit the Alerts API limit.

Priority

Priority is fixed and not configurable per channel:

Event	Priority
Monitor or browser check down	`P1`
Certificate invalid	`P1`
Recovery (close)	none sent
Domain or TLS certificate expiry warning	`P3`

An invalid certificate creates an alert with the alias sq-tls-invalid-<tls-check-id>-<alert-id>, and its recovery closes it.

Expiry alerts do not auto-close

Domain and TLS certificate expiry warnings are create-only: they key on the check plus the expiry date (sq-dns-expiry-<job-id>-YYYY-MM-DD, sq-tls-expiry-<tls-check-id>-YYYY-MM-DD), so repeated warnings for the same date collapse into one alert, but nothing ever closes it. Close those alerts yourself. Renewing does not close them, and since renewal moves the expiry date, the next warning creates a new alert while the old one stays open.

Delivery behavior

An event the service refuses is recorded as rejected and not retried. Other failures are retried, and if every attempt fails, the alert is dropped with no record in alert history, so pair this channel with a second one for anything you cannot afford to miss. See delivery guarantees.

Limitations

Heartbeat (cron) monitors, page speed alerts and DNS record changes do not reach these channels. See the coverage table.
Incidents and escalation policies do not page through Jira Service Management or Opsgenie.