Rootly Incident Management

Overview

Incidents are the primary resource in Rootly — the central record for any production issue, outage, or service degradation. Rootly is used by SRE and platform engineering teams to coordinate response in real time and drive continuous improvement via postmortems. In MSP environments, Rootly typically manages internal infrastructure incidents rather than per-client ticketing, but can be configured with team-based routing to support multi-customer workflows.

The incident system supports:

• Automated Detection - Incidents created from monitoring alert integrations (Datadog, PagerDuty, Prometheus, Grafana, Sentry, etc.)
• Manual Creation - On-call engineers and responders create incidents via Slack, web UI, or API
• AI-Assisted Analysis - find_related_incidents and suggest_solutions surface past patterns and recommendations
• Real-Time Coordination - Slack channel auto-creation, Zoom bridges, timeline tracking
• Post-Incident Learning - Automated postmortem generation and action item tracking

All read and write operations on incidents are available through the Rootly MCP tools.

MCP Tools

Core Incident Tools

AI Analysis Tools

Supporting Lookups

Discover Available Tools

Call list_endpoints to get the current list of all available API endpoints and tool names from the Rootly OpenAPI specification.

Key Concepts

Incident Lifecycle

┌───────────┐   Triage starts   ┌────────────┐   Contained   ┌───────────┐
│ detected  │ ─────────────────> │  in_triage │ ────────────> │ mitigated │
└───────────┘                   └────────────┘               └───────────┘
                                                                     │
                                                               Full fix done
                                                                     ▼
                                                               ┌──────────┐
                                                               │ resolved │
                                                               └──────────┘
                                                                     │
                                                             PIR complete
                                                                     ▼
                                                               ┌────────┐
                                                               │ closed │
                                                               └────────┘

Key lifecycle timestamps on the incident record:

Severity Levels

Severities are configurable per Rootly organization. Common conventions:

Note: Severity IDs are UUIDs in Rootly. Always call severities_get to map severity slugs to IDs before creating an incident.

Incident Status Values

Rootly uses free-text status descriptors alongside timestamps. Common values:

• detected — Newly created, not yet acknowledged
• in_triage — Actively being investigated
• mitigated — Impact contained, monitoring for recurrence
• resolved — Issue fixed, normal operation restored
• cancelled — False alarm or invalid incident

Field Reference

Common Workflows

Triage New Incidents

1. Call incidents_get with status=in_triage or status=detected, sorted by severity
2. For each high-severity incident, review title and summary
3. Call find_related_incidents with the incident_id to surface similar past incidents
4. Call suggest_solutions with the incident_id to get AI-generated remediation suggestions
5. Create action items via incidents_by_incident_id_action_items_post for each remediation step
6. Update status as the incident progresses

Create an Incident

1. Call severities_get to find the correct severity ID for the impact level
2. Call services_get to identify which service is affected
3. Call teams_get to find the on-call team to assign
4. Call incidents_post with title, severity_id, service_ids, team_ids
5. Attach any triggering alerts via incidents_by_incident_id_alerts_post

Investigate a Specific Incident

1. Find the incident via incidents_get or by sequential_id
2. Call find_related_incidents — look for recurring patterns (same service, same time of day, same symptoms)
3. Call suggest_solutions — surface past resolutions that worked for similar incidents
4. Review action items via incidents_by_incident_id_action_items_get
5. Review attached alerts via incidents_by_incident_id_alerts_get

Daily Incident Review

1. Call incidents_get with a 24-hour window and status=resolved
2. Count by severity for a daily health summary