Incident Response Playbook
A one-page playbook for when alerts fire. Maps directly to Incido’s incident stages — Triage, Active, Post Incident, and Closed — so responders know what to do and when to go public.
Roles, stage gates, and comms beats in one place — less improvisation, faster coordination.
On this page
Preview or copy each section below — paste into Notion, Confluence, or your wiki.
Response playbook
Incident response playbook
Use from first alert through closure. Pair with the timeline template to record what happened.
Incident card
| Field | Value |
|---|---|
| Title | [Short customer-facing name] |
| Deduplication key | [stable-key — same key merges in Triage/Active] |
| Stage | Triage → Active → Post Incident → Closed |
| Severity | Critical / High / Medium / Low |
| Affected components | [Component A, Component B] |
| Incident commander | [Name] |
| Comms lead | [Name] |
| Escalation policy | [Policy name] |
Stage checklist
Triage — assess before you broadcast
- Confirm new incident (check deduplication key / related alerts)
- Set severity and affected components
- Assign commander and comms lead
- Decide: status-page update needed now? Yes / No
Active — confirmed impact, full response
- Move to Active stage
- Page on-call via escalation policy
- Log key decisions on the timeline
- Publish status update if customer-visible
- Notify subscribers on meaningful stage changes
Post Incident — impact ended, follow-up remains
- Move to Post Incident when customers are no longer affected
- Publish resolved update on status page
- Capture follow-up tasks on the timeline
Closed — wrapped up
- Follow-up tasks owned (not necessarily done)
- Move to Closed
Roles
| Role | Owns |
|---|---|
| Incident commander | Coordination, decisions, timeline quality |
| Comms lead | Status page copy, subscriber updates, timing |
| Technical lead | Investigation, mitigation, recovery evidence |
When to escalate manually
- Wrong on-call paged → Bring in a user, team, or schedule on the incident
- No acknowledgement → escalation policy advances automatically
- Scope grows → raise severity and notify leadership per severity matrix
Customer update cadence
| Severity | First public update | Ongoing |
|---|---|---|
| Critical | ≤ 15 min | Every 30–60 min while impacted |
| High | ≤ 30 min if visible | Every 60 min |
| Medium | If visible | On material changes |
| Low | Rarely | N/A |
How to use this template
- Pin this in your wiki and link from on-call runbooks.
- Align severity names and escalation policies with your Incido org settings.
- Run a tabletop quarterly — walk one scenario through each stage.
Incido tracks stages, timeline, pages, acknowledgements, affected components, and status-page publishing from a single incident record. Explore incident management →
FAQs
Triage vs Active — what changes?
Triage is assessment without full response. Active means confirmed impact: paging, timeline, and public comms are in motion.
What is a deduplication key?
A stable identifier so related alerts merge into one incident in Triage or Active — fewer duplicate pages and a cleaner dashboard.
When do we publish to the status page?
When customer-facing components are degraded or down. Internal-only issues usually stay off the status page.
Put your process into practice
14-day free trial. On-call, incidents, and status pages — no credit card required.