Jira Service Management (On-Call)
Page a Jira Service Management (JSM) Operations — formerly Opsgenie — on-call team from KubeSense alerts. Uses the Opsgenie Alert API, so no native integration is required on the JSM side; it works for Opsgenie US/EU and JSM Operations.
note: Standalone Opsgenie is being retired (shutting down April 5, 2027); JSM Operations is the go-forward host. This channel supports both.
1. Create an API integration
- In JSM/Opsgenie, open the team that should receive the alerts.
- Add an API integration from that team's dashboard and copy its API key.
warning: It must be an API integration key. A personal key from API-key management cannot create alerts (401 Could not authenticate).
note: Create the integration from the team dashboard, not from the account settings. An integration added there is owned by that team, so Opsgenie assigns every alert it receives to that team automatically. The account-wide default API integration is not team-scoped — alerts created with it aren't assigned to anyone unless you set an Assignee team on the integration in Opsgenie. Atlassian also recommends a separate integration per monitoring system rather than reusing the default one.
Routing to multiple teams
You don't need a new integration per team. Pick whichever fits:
Option A — one channel, team chosen per alert (recommended). Set Team on the
channel as the default, then add a team label to any alert rule that should go
elsewhere. The label wins; the channel's team is the fallback.
- Create one API integration (account-level) and one KubeSense channel with
Team set to your default (e.g.
platform). - On an alert rule that belongs to another team, add the label
team = payments. - That rule pages
payments; every rule without the label pagesplatform.
This keeps a single channel and a single key no matter how many teams you have — routing lives with the alert, where it belongs.
Option B — a channel per team. Give each channel a different Team (same key), and select the channel on the rule or match it with Matching Labels. Useful when teams should also have different priorities or tags.
Option C — a team-owned integration per team (most isolation). Add an integration from each team's dashboard and leave Team blank — the team is implicit in the key. A team-scoped key can only touch that team's alerts, so a misconfigured channel can't page the wrong team.
note: For A and B the key must be allowed to assign to those teams — use an account-level integration, not a team-scoped one (a team key can only manage its own team's alerts). Team must be set on the channel for label routing to work: it guarantees a fallback, so an alert without a team label is never left unassigned.
2. Find your API URL
Use the base host for your deployment:
| Deployment | API URL |
|---|---|
| Opsgenie US | https://api.opsgenie.com |
| Opsgenie EU | https://api.eu.opsgenie.com |
| JSM Operations | https://api.atlassian.com/jsm/ops/integration |
3. Create the channel in KubeSense
- Alerts → Notification Channels → New.
- Type = Jira Service Management (On-Call).
- Fill in:
| Field | Required | Description |
|---|---|---|
| API Key | Yes | The team's Opsgenie API integration key (sent as Authorization: GenieKey …). Stored encrypted at rest. |
| API URL | Yes | The base host from step 2. |
| Team | No | Default Opsgenie/JSM team for alerts on this channel. An alert rule's team label overrides it, so one channel can route per alert. Leave blank when the integration is team-owned (the team is implicit). Comma-separate for several teams. See Routing to multiple teams. |
| Priority | No | Opsgenie priority P1–P5. Leave blank to derive from severity (critical→P1, error→P2, warning→P3, info→P5). |
| Tags | No | Comma-separated tags added to every alert. source:kubesense, severity:… and alertname:… are always added automatically. |
- Save, then Test — a low-priority test alert appears in JSM and auto-closes.
note: Requires the server env var KUBECOL_CONFIG_KEK (used to encrypt the stored API key). When editing a channel, the API key shows blank — leave it blank to keep the stored key. See Encryption & key rotation.
How it behaves
- On firing, an Opsgenie alert is created; repeated firings de-duplicate onto the same open alert.
- On resolve, that alert is closed automatically, so incidents auto-resolve.
- Each alert carries the summary, severity, value/threshold, and a link back to the alert in KubeSense.
note: De-duplication is per notification group, not per firing instance — one rule firing across 50 pods raises one Opsgenie alert covering the group, rather than 50 separate pages. This keeps the pager quiet and matches the standard Prometheus → Opsgenie behaviour.
Alerts appear in JSM/Opsgenie → Alerts and follow the team's routing and escalation policies.
Delivery uses Alertmanager's built-in Opsgenie support (opsgenie_config), so
retries, grouping, and the create/close lifecycle are handled by Alertmanager
itself — KubeSense doesn't sit in the alert path.
Verify end to end
Attach the channel to an alert rule, let it fire, and confirm the alert opens in JSM/Opsgenie → Alerts with a link back to KubeSense — then resolve the rule and confirm the alert auto-closes.
Custom templates
JSM supports message templates: create one under Settings → Alert Templates (type Jira Service Management) with an Alert title and a Description, preview it, then select it on the channel. See Templates.
note: JSM templates use Alertmanager template syntax ({{ range .Alerts }}, {{ .Labels.severity }}, {{ .Annotations.value }}) — the same dialect as the Slack/Teams/Email templates — because Alertmanager renders them directly. The alert title is capped at 130 characters by the Opsgenie API.
Common Errors
| Error | Cause | Fix |
|---|---|---|
401 / Could not authenticate | Wrong key type (personal API key) or wrong region URL | Use the team's API integration key and the API URL matching your region |
422 on create | Invalid field (e.g. bad priority) | Ensure priority is P1–P5 |