> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Incident Response Best Practices > How strong teams run incident response, and how to configure Rootly to match. A defined incident response process answers one question in advance: what happens next? When that's settled, responders spend their attention on the failure itself, not on working out who to notify, whether this warrants a status page update, or who's writing the timeline down. The coordination work still happens, accurately, without competing with the diagnosis. The best-run teams automate the predictable parts of that coordination outright, and lean on an agent for the parts that need judgment. The practices below are the ones we see consistently across teams that respond well; not the most sophisticated setups, the most repeatable ones. Each section describes what good looks like, then points to the part of Rootly that makes it stick. Find the row you're in on the maturity table and fix the next thing. | | Crawl | Walk | Run | | --------------- | ------------------------------------------ | ------------------------------------------------ | ----------------------------------------------------------------------- | | Automation & AI | Every step is manual, reminders are tribal | Workflows cover the repeatable steps | An agent handles lookups, updates, and gap-checking in-channel | | On-Call | A schedule exists | No coverage gaps, holidays and overrides handled | Multi-level escalation, coverage requests and shadowing built in | | Severity | Ad hoc judgment call | 3–4 defined levels with impact criteria | Severity drives automation: comms, roles, paging | | Roles | Whoever picks it up | Commander named at declaration | Roles auto-assigned by service and severity | | Playbooks | Individual experiences from responders | Docs exist somewhere | Playbooks attached to the incident, action items pre-assigned | | Comms | Someone remembers to post | Templates and a cadence | Automated updates to responders, stakeholders, and customers separately | | Retros | For the bad ones | Clear trigger criteria, consistent template | Every qualifying incident, action items tracked to close | ### Make sure an urgent page always reaches a human The most expensive failure isn't a slow response, it's a page nobody received. Before anything else, verify: 1. No gaps in your schedules. Coverage across time zones, holidays accounted for, overrides in place for planned time off. For 24/7 schedules, use [Rootly's Gap Detector](/on-call/schedules#enabling-24%2F7-coverage). This will make sure someone is always on-call for the schedule. 2. More than one level in every escalation policy. A single-level policy is a single point of failure. Level two should fire a short time after level one is paged and doesn't respond. 3. Critical alerts page a human target. Routing an alert with a High urgency to a Slack channel or a group with no on-call attached is the most common gap we find. Build a Dynamic Escalation Path in Rootly to define separate paging logic for each urgency level: create a path that pages a Schedule for all High urgency Alerts, versus pages a Slack channel for all low urgency Alerts. 4. Test the path. Trigger a test alert on each critical service quarterly and confirm who it woke up. In Rootly On-Call, make use of our [holiday calendars](/on-call/holiday-calendar#adding-a-holiday-calendar), [shift coverage requests](/on-call/request-coverage), and [shadowing](/on-call/on-call-shadowing) for new joiners. These features ensure you have complete coverage, and your alerts are always paging the right person. ### Define a Severity matrix to quickly communicate incident impact Severities are a simple way for your teammates to easily understand the impact of an incident. Define three or four levels. Define each one by what the customer experiences, not by which team is involved or how stressed anyone is. Write the response expectation into the definition: who gets paged, how fast, who gets told. A useful test: two engineers reading the same alert at 3am should pick the same severity without discussing it. Ask the Rootly AI Agent to help you choose the right severity:`@Rootly what severity should this incident be set to? Update it for me.` The Rootly AI Agent uses the context of the current incident, past incidents, and the Severity matrix you've configured in Rootly to propose an appropriate severity. Define your [severities](https://rootly.com/account/severities) from a SEV0 (most urgent) to a SEV3 (least urgent). However, you can change the labels, and update each severity's description in Rootly if your teams are familiar with a different framework. This helps set expectations with your teams when a new incident is declared. Severities can also be used to automate different processes, like automatically paging someone on the leadership team for a SEV0. You can measure the rate of incidents by severity too: for example, see which services are experiencing the highest rate of SEV2 incidents due to gaps in the deploy process. ### Assign individuals to roles as soon as possible Coordination failures cost more time than technical ones. At minimum: 1. **Incident commander**: owns the response, doesn't debug. The single most valuable role to make non-optional. 2. **Communications lead**: owns updates to stakeholders and customers so the commander doesn't context-switch. 3. **Scribe**: captures the timeline as it happens, not from memory afterward. Rootly's [AI Meeting Scribe](/ai/meeting-scribe) records and takes notes on your incident calls. This let's your human scribe focus on the incident and handle more impactful work, enabled by the AI Scribe's notes. Assign at declaration, not when someone notices they're missing. Where the assignment is predictable (like a service always mapping to the same team), automate it. If you aren't sure who to assign to a role, ask the Rootly AI Agent:`@Rootly assign the incident roles for me.` Rootly's AI Agent can be used by each responder to help them investigate the incident. If you do not have the AI Agent on, enable it under the [AI & Agent settings](https://rootly.com/account/ai/configurations). [Incident Roles](https://rootly.com/account/incident-roles) are configurable per team and are assigned per incident. You can automatically assign individuals to each role when their team is associated with an incident. ### Automate the first ten minutes with a playbook of steps The teams that respond fastest aren't improvising faster; they've removed the need to improvise completely by building a playbook. A good [playbook](/configuration/playbooks) is a short checklist of the first actions for a given failure mode, attached to the incident automatically, with each step already assigned to a role rather than a named person. Assigning to roles matters: named people go on vacation, roles don't. This ensures a repeatable process every time an incident is declared, so your responding teams can focus without missing any critical steps. [Playbooks](https://rootly.com/account/playbooks) attach to incidents based on conditions like impacted service and severity. Rootly will automatically create Action Items that carry the owners, due dates, and fields based on the Playbook steps. ### Structure your communications strategy Responders, internal stakeholders, and customers need different things at different intervals. Most teams collapse them into one channel and then either spam responders or leave executives to interrupt the response team asking for updates. Responders need the working channel, and don't mind the noise. Internal stakeholders need a scheduled update on a fixed cadence tied to severity. Every 30 minutes for SEV1, even if the update is "no change." Customers need a status page and honest, low-detail updates. Template the updates. Nobody writes well under pressure, and hand-written updates are the first thing to slip when things get hard. Use the Rootly AI Agent to help draft an update: `@Rootly update my status page with a summary of the current work the team is doing to resolve the issue.`