CalmStatusFictional worked example

Fictional example · verify your own facts

Identified incident status update example

See a fictional identified-stage status update and customer email that name a verified cause and correction underway without implying recovery.

By Electricity Studio · Published · Updated

Verified facts for this fictional scenario

  1. Affected workflow

    Password-reset email delivery

  2. Affected scope

    EU workspaces

  3. Customer impact

    Password-reset emails are delayed

  4. Unaffected state

    Existing sessions remain active

  5. Cause confirmed

    Configuration error in the email delivery service at 10:18 UTC

  6. Correction underway

    Corrected configuration rollout began at 10:22 UTC

  7. Current impact

    Password-reset emails are still delayed

  8. Recovery estimate

    Not yet available

  9. Current update

    10:30 UTC

  10. Incident state

    Remains open while the correction is underway

  11. Next update promised

    10:50 UTC

Customer-ready messages

  1. Identified update · status page

    Identified 10:30 UTC: We confirmed at 10:18 UTC that a configuration error in the email delivery service is delaying password-reset emails for EU workspaces. A corrected configuration began rolling out at 10:22 UTC. Password-reset emails are still delayed, while existing sessions remain active. We do not yet have a recovery estimate. The incident remains open while the correction is underway. We will share another update by 10:50 UTC, even if there is no material change.

  2. Identified update · customer email

    Subject: Cause identified for EU password-reset email delays We confirmed at 10:18 UTC that a configuration error in the email delivery service is delaying password-reset emails for EU workspaces. A corrected configuration began rolling out at 10:22 UTC. Password-reset emails are still delayed, while existing sessions remain active. We do not yet have a recovery estimate. The incident remains open while the correction is underway. We will send another update by 10:50 UTC, even if there is no material change.

Why these drafts stay bounded

  1. A verified cause is not recovery

    The drafts name the confirmed configuration error and correction rollout while keeping the continuing email delay explicit.

  2. Correction progress stays bounded

    Beginning a rollout does not establish that the correction has completed or changed customer impact.

  3. Unaffected state stays specific

    Existing sessions remain active; neither message turns that fact into a workaround, guarantee, or broader availability claim.

  4. Cadence stays bounded

    Both drafts promise the next communication at 10:50 UTC without turning that promise into a recovery estimate.

Draft from your verified facts.

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

Open the composer →

Use the incident update checklist →