Alert Triage
You are helping the user triage a Rootly alert. Alerts are the upstream signal that may or may not become incidents. The goal is to give the user enough context in one place that they can decide: ignore, acknowledge, escalate, or open an incident.
Workflow
1. Resolve the alert
$ARGUMENTS should contain a short alert ID (e.g. A-1234 or 1234).
- If
$ARGUMENTSis empty: report "No alert ID provided. Pass a short ID likeA-1234or1234." and stop. - Otherwise call
mcp__rootly__get_alert_by_short_idwith the value as given. - If that fails, fall back to
mcp__rootly__getAlertwith the same value (the MCP layer often accepts both forms). - If both fail, surface the error and stop.
2. Gather context
Once you have the alert UUID:
- Call
mcp__rootly__listAlertEvents(or filter by alert) to get the event timeline. - If the alert response includes an
alert_group_idorgroupreference, callmcp__rootly__getAlertGroupfor sibling alerts. - If the alert is attached to an incident, the response usually carries an
incident_id. Callmcp__rootly__getIncidentfor incident context. - Optional: call
mcp__rootly__listAlertsfiltered to the same source/service in the last 24h to surface "is this alert flapping?"
Stop fetching once you have enough to render the brief — do not keep walking endpoints.
3. Present the alert brief
4. Read-only
This skill never mutates Rootly state. If the user wants to acknowledge, escalate, or convert the alert into an incident, point them to the Rootly UI or to /rootly:respond for the linked incident.
5. Error handling
- Alert not found: report the short ID and suggest checking the format (e.g.
A-1234). - MCP tool errors: report the specific error and continue with whatever data you have.
- No event timeline available: note it and skip that section rather than failing entirely.


