CalmStatusPractical guide

After a resolved incident

How to write a customer-facing incident follow-up

Write a reviewed post-incident update that leads with customer impact, publishes only approved findings and actions, and keeps future commitments bounded.

  1. Define the audience and publication scope

    Before drafting, identify the customer audience, the channels your team will use, and the resolved incident covered by this follow-up. Your own process determines whether, where, and when to publish; this guide does not create a disclosure duty.

  2. Lead with customer-visible impact and time

    State the affected workflow, verified customer scope, and customer-visible start and resolution times with timezones. Put those facts before internal component detail so readers can understand what happened to them and for how long.

  3. Confirm recovery and the current observed state

    State what recovery your team verified, when it was verified, and the current observed service state. Keep any remaining backlog, limitation, or customer action explicit, and do not turn a current observation into a future availability guarantee.

  4. Include cause only when approved to publish

    Distinguish a verified cause from contributing factors, hypotheses, and unresolved questions. Include cause wording only after the responsible team has confirmed it and approved it for this audience; otherwise omit it rather than speculate.

  5. Separate completed actions from future commitments

    Name an action as completed only when the team has verified completion. Describe future work only as an owned commitment with its current scope and review point; do not present an idea, investigation, or planned change as completed prevention.

  6. State customer action and data effects precisely

    Say whether customer action is required and publish only reviewed instructions. If the incident affected data, transactions, notifications, or queued work, state only the impact and recovery facts your team has verified and approved for customer communication.

  7. Remove sensitive detail and complete review

    Exclude credentials, exploit paths, personal data, confidential customer or employee information, and unapproved vendor detail. Route security, privacy, legal, regulatory, contractual, SLA, and notification questions through your own required reviewers before publication.

  8. Align channels and retain the published record

    Keep impact, scope, times, approved findings, actions, and customer instructions consistent across status page, email, and in-app versions. Retain what was published, where, and when, then correct every used channel if an approved fact changes.

Draft from verified facts.

The free acknowledgment and resolution composer runs entirely in your browser.

Open the composer →

Use 4 free incident update templates →