Last updated: 2026-07-19
Incident Response Plan Template
A step-by-step incident response plan template for engineering teams. Define roles, communication channels, escalation paths, and post-mortem procedures.
Download our free incident response plan template. Used by engineering teams to structure their response to outages. Covers roles, detection, communication, resolution, and post-mortems.
Incident severity levels
Define 3-4 severity levels: SEV1 (critical: full outage, all users affected, immediate response required), SEV2 (major: key feature down, some users affected, respond within 15 minutes), SEV3 (minor: non-critical feature degraded, respond within business hours), SEV4 (cosmetic: visual issue, no user impact, fix in next release). Each level has defined response time, escalation path, and communication requirements.
Roles and responsibilities
Incident Commander: leads the response, makes decisions, coordinates communication. Technical Lead: investigates the root cause, implements the fix. Communications Lead: updates the status page, notifies stakeholders, manages customer messaging. Scribe: documents the timeline in real time. In small teams, one person may hold multiple roles. The key is that everyone knows their role before an incident starts.
Communication plan
Initial acknowledgment: post to status page within 5 minutes of detection. Updates: every 30 minutes during SEV1, every hour during SEV2. Resolution notice: when the incident is resolved, with a brief summary of what happened and what is being done to prevent recurrence. Post-mortem: published internally within 48 hours, shared with affected customers on request.
Post-mortem process
Every SEV1 and SEV2 incident gets a blameless post-mortem within 48 hours. Template sections: timeline of events, root cause, what went well, what went poorly, action items with owners and due dates. Post-mortems are shared with the full engineering team. Action items are tracked in your project management tool like any other task. The goal is learning, not blame.
- Define severity levels with response time targets
- Assign incident roles (Commander, Tech Lead, Comms, Scribe)
- Document escalation paths and on-call rotation
- Create status page update templates for each severity
- Set up alert channels with clear routing rules
- Write runbooks for the top 5 failure modes
- Schedule quarterly incident response drills
- Document post-mortem template and follow-up process
Frequently asked questions
Do we need an incident response plan if we are a 2-person team?
Yes. Even in a 2-person team, agreeing on who does what during an outage saves precious minutes. The plan can be simple: Alice investigates and fixes, Bob updates the status page and handles customer communication. Write it down before you need it. During a real incident, you will be glad you made decisions in advance.
How often should we update the plan?
Review and update your incident response plan quarterly, or after any SEV1 incident. Each post-mortem usually generates action items that improve the plan. After 3-4 incidents, your plan will be significantly better than when you started. The first version does not need to be perfect. Ship it, use it, improve it.
What is the most important part?
Clear alert routing. If the right person does not know there is an incident, nothing else matters. Make sure PingWatchdog alerts go to the right people (PagerDuty for on-call, Slack for team visibility). Test this monthly: trigger a test alert and verify the right people get notified.