Escalate a JSM alert through an escalation policy
jsm_escalate_alertImmediately push a JSM alert into an escalation policy when it isn't being picked up, bypassing the escalation timer. Pages the next responders now.
Instructions
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 of the schedule they agreed to. Confirm with the user before escalating on their behalf.
escalation_id is an escalation policy id — not a team id and not a schedule id. The three are separate objects with separate ids, and passing the wrong one fails with 422 rather than escalating to something adjacent.
Examples:
"Nobody has picked this up, escalate it" -> get the escalation id for the team, then escalate
Constraints and errors:
HTTP 422 or a failed request status usually means escalation_id is not an escalation, or belongs to a different team than the alert.
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. | |
| escalation_id | Yes | Id of the escalation policy to escalate through. This is an escalation id, not a team or schedule id — the three are separate objects with separate ids. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | No | ||
| alert_id | Yes | ||
| requestId | No |