# Incident update publishing checklist

Use this checklist before publishing a status-page, customer-email, or in-app incident update. Complete it from your team's verified fact record.

- [ ] **Confirm the current scope and state** — Name the affected service or workflow, who is affected, and whether the incident is investigating, identified, monitoring, or resolved. Use only the state your team has confirmed.
- [ ] **Separate facts from hypotheses** — Publish observed behavior and verified findings. Keep suspected causes, unconfirmed timelines, and internal debugging theories out of the customer update.
- [ ] **State customer impact plainly** — Describe what customers may be unable to do or may experience. Avoid internal component names when the customer-facing workflow is clearer.
- [ ] **Avoid unsupported restoration estimates** — Give a restoration time only when the team can support it. Otherwise state that work continues and provide the time of the next update.
- [ ] **Set the next communication time** — Name a specific next-update time or say that the next message will follow a defined state change. Silence should never be the implied cadence.
- [ ] **Check every channel for consistency** — Confirm that status-page, email, and in-app messages use the same incident state, scope, timestamps, and next-update commitment before publishing.

This checklist supports factual writing. It does not advise on remediation, security disclosure, legal duties, contractual notice, or regulated communications.

Source: https://app.electricity.studio/calmstatus/guides/incident-update-checklist/