Incident Management Ready Reckoner
Severity by impact
| Level | Typical impact | Response |
|---|---|---|
| P1 / Critical | Major customer-facing outage, payment failure, widespread production failure, serious security or data risk | Immediate response, incident command, full escalation |
| P2 / High | Major feature unavailable, significant degradation, limited regional impact | Immediate investigation; escalate if impact grows |
| P3 / Medium | Limited impact, workaround available, non-critical service affected | Normal engineering response |
| P4 / Low | Minor issue with little or no operational impact | Track as normal work |
Roles
| Incident Commander | Owns coordination, severity, assignments, and when recovery can be declared. |
|---|---|
| Technical responder | Investigates and remediates. Reports back instead of running a second incident in chat. |
| Communications lead | Owns status page, support macros, and stakeholder updates. |
| Subject matter expert | Joins for a named system. Do not invite twenty people because the incident is serious. |
Event, alert, incident, problem
| Event | Something happened. CPU reached 82%. |
|---|---|
| Alert | A condition worth notifying. CPU stayed above 80% for 10 minutes. |
| Incident | Meaningful or threatened service impact that needs coordinated response. |
| Problem | The underlying condition behind one or more incidents. |
Example P1 escalation
| 0 min | Page primary on-call. |
|---|---|
| 5 min | Page secondary. |
| 10 min | Page engineering lead. |
| 15 min | Widen the incident response. |
Metrics to define in writing
| MTTD | Time from customer impact to detection. |
|---|---|
| MTTA | Time from alert to acknowledgement. |
| MTTR | Define restore, recover, resolve, or repair before you report it. Time to restore service is usually the useful one. |
| Time to communicate | Time from confirmed customer impact to the first status update. |