Incident Communication Template

The incident commander or a designated communications lead. It should not be the same person debugging the issue. Communication requires a clear head, empathy for customers, and the ability to step back from technical details. In small teams, the PM or a customer success lead is a good fit.

Yes, if the incident affected service quality (data delays, performance degradation, error rates). No, if the incident was caught and resolved before any customer impact. The threshold: if a customer reviewed their logs or monitoring and could detect the issue, disclose it proactively.

Own the communication. Your customers pay you, not your cloud provider. State the facts: "Our database provider experienced an outage that affected [service]." Do not blame the provider by name unless it is already public knowledge (e.g., a well-publicized AWS outage). Focus on what you are doing to mitigate and when you expect resolution.

For major incidents (affecting 10%+ of customers or lasting 1+ hour), yes. Public post-incident reviews build trust. For minor incidents, an internal review is sufficient. Companies like Cloudflare, GitLab, and Linear publish detailed post-incident reviews. Their transparency has become a competitive advantage.

Track incidents per month, mean time to detect (MTTD), and mean time to resolve (MTTR). Review trends quarterly. Most incident reduction comes from three investments: better monitoring (reduce MTTD), runbooks for common failure modes (reduce MTTR), and safer deployment practices (reduce frequency). The [Product Analytics Handbook](/analytics-guide) covers how to set up the tracking systems to measure these reliability metrics. ---