Run a custom action on a JSM alert
jsm_execute_alert_actionRun a configured custom alert action on a Jira Service Management alert using its full ID and exact action name; then verify completion via request status.
Instructions
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_status using the returned requestId.
Do not guess an action name. There is no endpoint that lists them, so a plausible-sounding guess is exactly as likely to be a real destructive automation as it is to be nothing. An unrecognised name is accepted and silently does nothing, which means a successful receipt is not evidence that anything ran. Ask the user which action they mean, and confirm before running it.
Constraints and errors:
Names are configured per integration, so an action that exists for one alert's source may not exist for another's.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes | Full alert id, e.g. '9b251e07-73c9-4907-9996-8cb53a6a20d0-1704440650350'. This is NOT the short tinyId shown in the JSM UI — get the full id from jsm_list_alerts first. | |
| action_name | Yes | Name of a custom action configured for your organisation's integrations. Not free text: an unrecognised name is accepted and then does nothing. Ask the user what actions exist rather than guessing a plausible one. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | No | ||
| alert_id | Yes | ||
| requestId | No |