Jira Alerts (JSM Operations)

Push a JSM alert into an escalation policy immediately, rather than waiting for it to escalate on its own. Use this when an alert is not getting picked up and waiting out the escalation timer is not acceptable. It pages the next people in that policy now. Args: - alert_id (string): the full alert id (not the tinyId) - escalation_id (string): id of the escalation policy to run Returns: { "requestId": string, "result": string, "alert_id": string } IMPORTANT: this action is asynchronous. Verify with jsm_get_request_status using the returned requestId. This pages people out of band, ahead…

Run one of your organisation's own custom alert actions — the buttons a team wires up on an integration, like "Restart service" or "Roll back deploy". What these do is entirely up to whoever configured them, and this server cannot see it. An action name is a request to run somebody's automation against production. Args: - alert_id (string): the full alert id (not the tinyId) - action_name (string): the configured action's name, exactly as configured Returns: { "requestId": string, "result": string, "alert_id": string } IMPORTANT: this action is asynchronous. Verify with jsm_get_request…

Retrieve the full detail of a single JSM alert, including its description, custom details/extraProperties, responders, tags and dedupe count. Use this after jsm_list_alerts when you need the payload an integration attached to the alert (host, service, metric values, runbook links) — the list endpoint returns a thinner record without the description or details map. Args: - identifier (string): the full alert id, or an alias when identifier_type='alias' - identifier_type ('id' | 'alias'): default 'id' - response_format ('markdown' | 'json'): default 'markdown' Returns (json format): a s…

Get a temporary download URL for one file attached to a JSM alert. Args: - alert_id (string): the full alert id (not the tinyId) - attachment_id (string): from jsm_list_alert_attachments Returns: { "alert_id": string, "attachment_id": string, "url": string } **The URL expires**, and it is pre-authorised — anyone holding it can fetch the file without credentials for as long as it lasts. Hand it to the user to open; do not paste it anywhere it will be stored or shared, and fetch a fresh one rather than reusing an old one. This server does not download the file. It returns the URL and sto…

Return the responders who take over the next shift on a JSM schedule, and when that shift begins. Use this for handover messages and for deciding whether an alert can wait for the next rotation. Args: - schedule_id (string): schedule id, or name if schedule_identifier_type='name' - schedule_identifier_type ('id' | 'name'): default 'id' - date (string, optional): ISO 8601 reference point; "next" is computed relative to it. Defaults to now - flat (boolean): default true — flat list of user identifiers; false shows rotation/escalation nesting - response_format ('markdown' | 'json'): d…

Return the responders currently on-call for a JSM schedule, optionally evaluated at a past or future timestamp. This is the tool for "who do I wake up?" and, with the 'date' argument, for "who was on-call when this incident started?" — which is often the more useful question during a post-incident review. Args: - schedule_id (string): schedule id, or name if schedule_identifier_type='name' - schedule_identifier_type ('id' | 'name'): default 'id' - date (string, optional): ISO 8601 timestamp to evaluate at; defaults to now - flat (boolean): default true — flat list of user identifiers…

Check whether an asynchronous alert action actually succeeded. Every JSM alert write (acknowledge, close, add note, assign, snooze) returns immediately with a requestId and does NOT apply the change synchronously. Pass that requestId here to confirm the action landed — this is the correct way to verify a write, rather than immediately re-reading the alert and finding it unchanged. Args: - request_id (string): the requestId returned by a write tool - response_format ('markdown' | 'json'): default 'markdown' Returns (json format): { "action": string, // e.g. "Acknowledge" …

Return the on-call rotation periods for a JSM schedule — who covers each shift, and exactly when each shift starts and ends. This is the tool for any question about shift boundaries rather than a single moment: "when does the current shift end?", "when is the handover?", "who covers the weekend?", "show me next week's rota". Answering those by calling jsm_get_on_call at guessed timestamps takes many calls and still cannot find a boundary exactly; this takes one. Responders are resolved to names, so periods come back with people rather than bare account ids. Args: - schedule_id (string): s…

List the files attached to a JSM alert — screenshots, logs, dashboards someone captured while working it. Attachments carry evidence the alert's text does not: the graph that showed the spike, the stack trace, the config that was wrong. Check them before concluding an alert has no context. Args: - alert_id (string): the full alert id (not the tinyId) - limit (number): 1-100, default 20 - cursor (string, optional): the 'next_cursor' from a previous response - response_format ('markdown' | 'json'): default "markdown" Returns (json format): { "attachments": [{ "id": string, "atta…

List the system activity log for a JSM alert — every state transition, notification, escalation and automated action, newest first by default. Use this to answer "why did nobody get paged?" or "when was this escalated and to whom?". Logs are system-generated; human comments live in jsm_list_alert_notes instead. Args: - alert_id (string): the full alert id (not the tinyId) - limit (number): 1-100, default 20 - order ('asc' | 'desc'): default 'desc' - offset (string, optional): opaque cursor from a previous response's next_cursor - response_format ('markdown' | 'json'): default 'mark…

List the notes (human comments) recorded on a JSM alert's activity timeline, newest first by default. Notes are where responders write triage context, and where integrations append re-fire and resolution updates for a deduplicated alert. Read them before acting on an alert so you don't repeat work someone already did. Args: - alert_id (string): the full alert id (not the tinyId) - limit (number): 1-100, default 20 - order ('asc' | 'desc'): default 'desc' - offset (string, optional): opaque cursor from a previous response's next_cursor - response_format ('markdown' | 'json'): defaul…

Description is built at runtime.

Report every toolset this server knows about, whether it is currently loaded, and how to load one that is not. Call this before telling the user something is impossible. This server carries far more of the Jira Service Management Operations API than any one install registers — the operator chooses which families load, so an absent tool usually means "not enabled here", not "not supported". This tool tells you which of the two it is, and names the exact environment variable to change. It takes no arguments, makes no API call, and needs no credentials, so it also answers when the token is miss…

List a team's heartbeats — the dead-man's switches that alert when an expected ping stops arriving. A heartbeat is how you learn that a job died rather than failed: something pings JSM on a schedule, and JSM alerts when the ping does not come. Args: - team_id (string): the owning team, from jsm_list_teams - name (string, optional): filter to one heartbeat by name - limit (number): 1-100, default 20 - offset (number): records to skip, default 0 - response_format ('markdown' | 'json'): default 'markdown' Returns (json format): { "heartbeats": [ { "name": string, "status": "Responsiv…

Send a ping, resetting a heartbeat's timer and clearing it if it had expired. Args: - team_id (string): the owning team - name (string): the heartbeat to ping Returns: { "pinged": true, "name": string, "message": string } The response is only an acknowledgement — "PONG - Heartbeat received" — not the heartbeat's record. Nothing about the heartbeat's state comes back, so report that the ping was accepted rather than describing the heartbeat. The API answers PONG whether or not a heartbeat by that name exists, and answers it on sites whose plan excludes heartbeat monitoring entirely (bot…

Remove properties from a JSM alert by key. Args: - alert_id (string): the full alert id (not the tinyId) - keys (string[]): the property keys to remove — keys, not values Returns: { "requestId": string, "result": string, "alert_id": string } IMPORTANT: this action is asynchronous. Verify with jsm_get_request_status using the returned requestId. A key that is not present is not an error, so a receipt here does not prove anything was removed. Read the alert back if that matters. Constraints and errors: - Needs delete:ops-alert:jira-service-management, a separate grant from write:ops-a…

Remove one or more tags from a JSM alert. Args: - alert_id (string): the full alert id (not the tinyId) - tags (string[]): the tag names to remove Returns: { "requestId": string, "result": string, "alert_id": string } IMPORTANT: this action is asynchronous. Verify with jsm_get_request_status using the returned requestId. Removal matches exactly and is case-sensitive, so removing 'DB' leaves 'db' in place. Read the alert's current tags with jsm_get_alert first rather than guessing the casing — a removal that silently matches nothing still returns a successful receipt. Constraints and e…

Silence a JSM alert's notifications until a specific instant, after which it resumes as if untouched. Snoozing is the right tool for "we know, and there is nothing to do until the maintenance window ends" — it stops the paging without pretending the alert is resolved. Closing it would remove it from the open queue and lose the fact that it is still an open problem. Args: - alert_id (string): the full alert id (not the tinyId) - end_time (string): ISO 8601 instant with an offset, e.g. "2026-09-05T18:30:00Z" Returns: { "requestId": string, "result": string, "alert_id": string } IMPORTANT…

Return an acknowledged JSM alert to unacknowledged, so escalation notifications resume. Use this when someone acked an alert they cannot actually work — picked it up by mistake, or got pulled onto something else — and it needs to go back into the escalation path so the next responder is paged. It does not close, snooze or reassign the alert. Args: - alert_id (string): the full alert id (not the tinyId) Returns: { "requestId": string, "result": string, "alert_id": string } IMPORTANT: this action is asynchronous. Verify with jsm_get_request_status using the returned requestId. This restar…

Overwrite one field on an existing JSM alert: its priority, its message, or its description. This is how an alert gets corrected once triage knows more than the integration that raised it did — a P3 that turns out to be customer-facing, a message that says "check failed" when it should say which check, a description that should carry what has been tried. Args: - alert_id (string): the full alert id (not the tinyId) - field ('priority' | 'message' | 'description'): which field to overwrite - value (string): the new value There are no 'user' or 'source' arguments here, unlike the other …

Replace the text of an existing note on a JSM alert. Use it to correct a note you just wrote — a wrong hostname, a stale conclusion. Prefer adding a new note with jsm_add_alert_note for anything that reads as a development rather than a correction: the timeline is the record of what responders knew and when, and editing history out of it costs more than an extra line. Args: - alert_id (string): the full alert id (not the tinyId) - note_id (string): id of the note to edit, from jsm_list_alert_notes - note (string): the replacement text Returns the updated note: { "alert_id", "note_id",…

Change a heartbeat's interval, alert settings or enabled flag. Args: - team_id (string), name (string): which heartbeat — the name goes in the query string, not a path id - interval, interval_unit, description, enabled, alert_message, alert_priority, alert_tags Returns: { "heartbeat": { "name": string, ... } } Setting enabled=false is the reversible way to stop a heartbeat alerting — during a planned outage, say. While disabled it raises nothing however long the silence, which is easy to forget to undo. Lengthening the interval widens the window in which a dead job goes unnoticed. Say …