> ## 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 Management Glossary > Plain-English definitions of incident management terms — incident commander, escalation policy, alert fatigue, MTTR, SEV levels, runbooks, and more. Clear definitions for the terms you'll meet across Rootly and in incident management generally. Entries link to the Rootly docs page where you can put the concept to work — and the most-asked-about terms have full deep-dive entries with formulas, tables, and worked examples. ## Action item An action item is a concrete follow-up task that comes out of an incident or retrospective — fix the bug, add the missing alert, update the runbook. Tracking them to completion is how incidents actually make systems better. Learn more: [Action Items & Tasks](/incidents/action-items/action-items). ## Alert An alert is a signal from a monitoring or observability tool that something may be wrong. Alerts feed into routing, grouping, and escalation so the right responder is notified. Not every alert becomes an incident. Learn more: [Alerts](/alerts/alerts). ## Alert deduplication Alert deduplication collapses repeated notifications for the same underlying problem into a single alert, so responders see one actionable signal instead of a flood. Learn more: [Alert Deduplication](/alerts/alert-deduplication). ## Alert fatigue Alert fatigue is the desensitization responders develop when they receive too many noisy, low-value, or false-positive alerts — leading to slower responses and missed real incidents. Deduplication, grouping, routing, and urgency tuning are the main defenses. Learn more: [Alert Deduplication](/alerts/alert-deduplication) and [Alert Urgency](/alerts/alert-urgency). Deep dive: [What is alert fatigue?](/glossary/alert-fatigue) ## Alert grouping Alert grouping bundles related alerts — same service, same time window, similar payloads — into one group so they can be triaged and resolved together. Learn more: [Alert Grouping](/alerts/alert-grouping). ## Alert routing Alert routing evaluates incoming alerts against rules and sends each one to the right team, service, or escalation path the first time. Routing rules typically match on alert source, payload fields, and urgency. Learn more: [Alert Routing](/alerts/alert-routing). ## Error budget An error budget is the amount of unreliability an SLO allows — the gap between your target and 100%. It's SRE's tool for balancing reliability work against shipping speed. Full entry: [What is an error budget?](/glossary/error-budget) ## Escalation policy An escalation policy is the ordered chain of people or teams to notify when an alert isn't acknowledged in time — for example, page the on-call engineer, then their backup, then the team lead. It guarantees nothing falls through the cracks. Learn more: [Escalation Policies](/on-call/escalation-policies). ## Heartbeat monitoring A heartbeat is an expected periodic signal from a system ("I'm alive"). When the signal stops arriving, an alert fires — catching silent failures that produce no error at all. Learn more: [Heartbeats](/on-call/heartbeats). ## Incident An incident is any unplanned disruption or degradation of a service that requires a response — from a full outage to elevated error rates or a security event. In Rootly, an incident is a structured record with a severity, status, timeline, roles, and follow-ups. Learn more: [Incident Management](/incidents/incidents). ## Incident channel (war room) An incident channel — commonly called a war room — is the dedicated space, physical or virtual, where responders coordinate during a major incident. Rootly favors the calmer "incident channel" over the militaristic framing. Full entry: [What is an incident channel?](/glossary/war-room) ## Incident commander The incident commander (IC) is the single person accountable for driving an incident to resolution: coordinating responders, making decisions, and keeping communication flowing. The IC directs the response but doesn't have to fix the issue personally. Rootly assigns incident roles like IC automatically when an incident starts. Learn more: [Incident Roles](/incidents/incident-roles/incident-roles). ## Incident management Incident management is the end-to-end discipline of detecting, responding to, resolving, and learning from incidents — the processes, roles, and tooling that keep services reliable. Full entry: [What is incident management?](/glossary/incident-management) ## Incident response Incident response is the hands-on work of an incident: triaging, mitigating, communicating, and resolving. It's the "doing" inside the broader incident management discipline. Full entry: [What is incident response?](/glossary/incident-response) ## Incident roles Incident roles are the named responsibilities in a response — incident commander, communications lead, scribe, operations lead — so everyone knows who is doing what. Rootly assigns and tracks roles per incident. Learn more: [Incident Roles](/incidents/incident-roles/incident-roles). ## Incident severity (SEV levels) Severity expresses how much impact an incident has, usually on a scale from SEV1 (critical, all-hands) down to SEV4/SEV5 (minor). Severity drives who gets paged, how fast, and what gets communicated. Rootly lets you define your own severity levels and tie automation to them. Learn more: [Severities](/configuration/severities). Deep dive: [SEV levels explained](/glossary/sev-levels) and [severity vs priority](/glossary/severity-vs-priority). ## Incident timeline The incident timeline is the chronological record of everything that happened during an incident — status changes, key decisions, messages, and events — captured automatically so the retrospective starts from facts instead of memory. Learn more: [Incident Timeline](/incidents/incident-timeline/incident-timeline). ## Incident triage Triage is the first-pass assessment of an incoming incident or alert: how bad is it, who does it affect, and how urgently does it need a response. Full entry: [What is incident triage?](/glossary/incident-triage) ## Live call routing Live call routing gives your customers or internal users a phone number that rings the current on-call responder directly, following your schedules and escalation policies. Learn more: [Live Call Routing](/on-call/live-call-routing). ## MTBF (mean time between failures) MTBF measures the average time a system runs between failures — a reliability indicator that pairs with MTTR to express availability. Full entry: [MTBF explained](/glossary/mtbf) ## MTTA (mean time to acknowledge) MTTA measures the average time between an alert firing and a responder acknowledging it. It's the primary signal of how quickly your paging and escalation setup actually reaches humans. Learn more: [On-Call Metrics](/on-call/on-call-metrics). Deep dive: [MTTA explained](/glossary/mtta) and [MTTA vs MTTR](/glossary/mtta-vs-mttr). ## MTTR (mean time to resolution) MTTR measures the average time from incident start to resolution. It's the most common top-level indicator of incident response health, and shrinking it is the goal of most process and tooling investments. Learn more: [Analytics & Dashboards](/metrics/default-metrics). Deep dive: [MTTR explained](/glossary/mttr) and [MTBF](/glossary/mtbf). ## On-call schedule An on-call schedule defines who is responsible for responding to alerts at any given time, rotating responsibility across a team in shifts. Good schedules balance coverage with responder health. Rootly supports rotations, overrides, and shift swaps. Learn more: [On-Call Schedules](/on-call/schedules). ## Paging Paging is the act of actively notifying an on-call responder — by push notification, SMS, or phone call — that they're needed now. A "page" cuts through normal notification channels. Learn more: [Manual Paging in Rootly](/alerts/manual-paging). ## Problem management (incident vs problem) In ITIL terms, an incident is the disruption; a problem is its underlying cause. Problem management hunts root causes across incidents. Full entry: [Incident vs problem](/glossary/incident-vs-problem) ## Retrospective (postmortem) A retrospective (also called a postmortem) is the structured review after an incident: what happened, why, how the response went, and what will prevent recurrence. Blameless retrospectives focus on systems rather than individuals. Learn more: [Retrospectives](/retrospectives/retrospectives). Deep dive: [retrospective vs postmortem](/glossary/retrospective-vs-postmortem) and [how to run a retrospective](/concepts/incident-retrospective). ## Runbook / playbook A runbook (or playbook) is a predefined set of steps for handling a specific scenario — what to check, who to involve, and how to mitigate. Rootly playbooks attach those steps directly to incidents so responders don't work from memory. Learn more: [Playbooks](/configuration/playbooks). Deep dive: [What is a runbook?](/glossary/runbook) and [runbook vs playbook](/glossary/runbook-vs-playbook). ## Service catalog A service catalog is the inventory of your services and their metadata: owners, teams, dependencies, and tooling. Incident response uses it to answer "what is affected and who owns it?" instantly. Learn more: [Catalog](/catalogs). ## SLA / SLO / SLI An SLI measures service behavior, an SLO is your internal target for that measurement, and an SLA is the external contract with consequences. Full entry: [SLA vs SLO vs SLI](/glossary/sla-vs-slo-vs-sli) ## Status page A status page communicates service health and incident updates to customers or internal stakeholders. Public status pages reduce support load during incidents; private ones keep internal teams aligned. Learn more: [Status Pages](/configuration/status-pages). ## Sub-statuses Sub-statuses add organization-specific stages to the incident lifecycle (for example "investigating — vendor engaged") beyond the standard started/mitigated/resolved flow, so reporting reflects how your team actually works. Learn more: [Statuses & Sub-Statuses](/incidents/incident-lifecycle). ## Workflow In Rootly, a workflow is an automation rule: when conditions match (an incident is created, a severity changes, an alert fires), Rootly performs actions — creating Slack channels, notifying stakeholders, filing Jira tickets, or updating status pages — the same way every time. Learn more: [Workflows](/workflows/workflows).