Before you publish
Incident update checklist for small SaaS teams
Use this six-step checklist to turn verified incident facts into a clear, consistent customer update without inventing certainty.
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.
Free Markdown checklist
Incident update publishing checklist
Keep a copy-and-edit set of six factual checks beside your team's incident record before publishing.
Download the free Markdown checklist
# 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/
Draft from verified facts.
The free acknowledgment and resolution composer runs entirely in your browser.
Open the composer →