Stage 6 · Operate
Incident Response & RCA
Stakeholder Communication
Status pages, internal comms, and customer-facing updates — keeping everyone informed during incidents.
Communication Principles
Incident communication follows three principles: be fast, be accurate, and be consistent. Speed without accuracy creates misinformation. Accuracy without speed creates silence. Consistency across channels prevents confusion.
When you do not communicate, people assume the worst. Send an update even if you have limited information. 'We are aware and investigating' is better than nothing.
Status Page Updates
Your status page is the single source of truth for external communication. Update it at regular intervals (every 15-30 minutes) or whenever the status changes. Customers check the status page first.
status_page_policy:
update_frequency:
investigating: "Every 15 minutes"
identified: "Every 15 minutes"
monitoring: "Every 30 minutes"
resolved: "Final update"
components:
- name: "API"
impact: "Degraded performance"
- name: "Web Dashboard"
impact: "Fully operational"
- name: "Data Pipeline"
impact = "Delayed processing"
severity_mapping:
SEV1: "Major Outage"
SEV2: "Partial Outage"
SEV3: "Degraded Performance"
SEV4: "Minor Impact"Internal Communication
Internal communication keeps the engineering team, leadership, and affected teams informed. Use the dedicated update channel for regular updates. Avoid cluttering the war room channel with status updates.
## [HH:MM] Status Update — [Incident Title]
**Severity:** SEV[X]
**Status:** [Investigating / Identified / Mitigating / Monitoring / Resolved]
**Duration:** [X minutes/hours]
**Impact:**
- [Number] users affected
- [Services] impacted
- [Error rate / latency / availability impact]
**Current Actions:**
- [What the team is currently doing]
**Next Steps:**
- [What will happen next]
**Next Update:** [Time of next update]Customer Communication
Customer-facing communication should be clear, concise, and non-technical. Avoid internal jargon. Focus on what is affected, what you are doing about it, and when they can expect a resolution.
| Good Communication | Bad Communication |
|---|---|
| We are experiencing elevated error rates for the API. Our team is investigating. | We had a bad deploy and are rolling it back. |
| Some users may see slower response times. We expect resolution within 30 minutes. | The system is having issues. We will fix it soon. |
| This incident affects the /users endpoint. Other services are unaffected. | Multiple services are down. |
Communication Templates
Pre-written templates reduce cognitive load during incidents. Have templates ready for common scenarios: initial notification, status updates, resolution, and postmortem summary.
## Initial Notification (within 15 minutes)
Subject: Service Degradation — [Service Name]
We are currently experiencing [brief description of issue].
Our engineering team has been engaged and is actively investigating.
**Affected services:** [list]
**Impact:** [description]
**Started:** [time UTC]
We will provide an update within 30 minutes or sooner if the
situation changes.
## Resolution Notification
Subject: Service Restored — [Service Name]
The issue affecting [service name] has been resolved.
**Duration:** [total time]
**Impact:** [summary of impact]
**Root cause:** [brief, non-technical description]
A detailed postmortem will be published within 5 business days.
## Postmortem Summary (for email distribution)
Subject: Post-Incident Review — [Incident Title] — [Date]
**Summary:** [1-2 sentence summary]
**Duration:** [start time] to [end time] UTC
**Impact:** [user impact description]
**Root cause:** [non-technical explanation]
**Resolution:** [what fixed it]
**Prevention:** [what we are doing to prevent recurrence]
Full postmortem: [link]Post-Incident Communication
After the incident, communicate the results of your investigation. Share the postmortem with affected stakeholders. This builds trust and shows that you take reliability seriously.
When communicating after an incident, explain what you are doing to prevent recurrence, not just what caused the problem. Stakeholders care about future reliability, not just past failures.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.