Create a JSM alert
jsm_create_alertCreate an alert in Jira Service Management to page responders and start routing an incident through team escalation rules. Use when a problem requires immediate human action and on-call follow-up.
Instructions
Create a new alert in Jira Service Management Operations.
This pages people. A created alert enters the team's routing and escalation rules exactly as one raised by a monitoring integration would, so someone's phone may ring. Create one when a human wants an incident tracked and escalated — not to leave a note, which is jsm_add_alert_note, and not to record something nobody needs to act on.
Args:
message (string): one-line summary. The ONLY required field.
alias (string, optional): de-duplication key — see below
description (string, optional): longer detail, impact, what to try
priority ('P1'..'P5', optional): P1 highest; omit to let routing rules decide
responders (array, optional): [{ id, type }] with type 'user' | 'team' | 'escalation' | 'schedule'
visible_to (array, optional): [{ id, type }] with type 'user' | 'team'; max 50
entity (string, optional): what the alert is about, e.g. 'payments-api'
tags (string[], optional)
actions (string[], optional): names of custom actions configured in your org
extra_properties (object, optional): arbitrary key/value context
note (string, optional): note recorded on the new alert's timeline
source (string, optional): where the alert came from, e.g. 'claude-mcp'
There is no 'user' argument, unlike the other write tools: this endpoint has no actor override, and the alert is created as the owner of the credentials.
Returns: { "requestId": string, "result": string, "alias": string }
IMPORTANT: this is asynchronous, and it does not return the new alert's id. The response confirms the request was accepted, not that an alert exists. Unusually for this API the status code is 200 rather than 202, which does not make it synchronous. To get the id: call jsm_get_request_status with the returned requestId, or — if you set an alias — jsm_get_alert with identifier_type='alias'.
Alias is the de-duplication key, and it is the difference between a safe retry and a silent no-op. Creating with an alias that already has an OPEN alert does not create a second alert; it increments the existing one's count and leaves everything else alone. That makes a retried create safe. It also means reusing an alias from an earlier, still-open incident quietly does nothing visible — so make aliases specific to the occurrence, not to the check.
Examples:
"Raise a P1 for the payments API being down" -> message="Payments API returning 503", priority="P1", entity="payments-api"
Retryable create -> alias="payments-api-503-2026-09-05T11:00"
Constraints and errors:
Needs write:ops-alert:jira-service-management alongside the read scope. A token with only read scopes gets 403.
Responders bypass the team's routing rules. Omit them unless you specifically want to route around routing.
HTTP 422 usually means a responder id doesn't exist or its type is wrong.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Note recorded on the new alert's timeline. | |
| tags | No | Tags for searching and grouping, e.g. ['db', 'prod']. | |
| alias | No | Client-defined de-duplication key. Creating against an alias that already has an OPEN alert does not create a second one — it increments that alert's count. This is the field that makes creation safe to retry, and the field that makes it silently do nothing if reused carelessly. | |
| entity | No | What the alert is about — a host, service or application, e.g. 'payments-api'. | |
| source | No | Free-text source label shown in the alert activity log, e.g. 'claude-mcp'. | |
| actions | No | Names of custom actions your organisation has configured for alerts. Not free text — an unrecognised name is ignored rather than rejected. | |
| message | Yes | One-line summary of what is wrong, read first by whoever gets paged. The only required field. | |
| priority | No | P1 is highest, P5 lowest. Omitted lets the routing rules decide. | |
| responders | No | Who to notify. Omit to let the team's routing rules decide, which is usually what you want — naming responders explicitly bypasses routing. | |
| visible_to | No | Restricts who can see the alert, beyond the responders. Max 50 entries. Omit for team-default visibility. | |
| description | No | Longer detail: impact, how to reproduce, what to try. Shown on the alert page. | |
| extra_properties | No | Arbitrary key/value context carried on the alert, e.g. {'region': 'us-east-1'}. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | ||
| result | No | ||
| requestId | No |