AIWorkDex
Customer Support Practice

Run a checked incident-update cycle in Statuspage

Maintain one current customer status from investigation through resolution while engineers continue repair work.

Preparation
90 minutes to prepare; updates continue for the incident duration
Difficulty
Advanced
Task
Publish incident updates
Back to the Task: Publish incident updates

Before you start

Get what you need before you start

  • Assign the technical incident lead and a separate communication owner when staffing allows.
  • List the services and customer-visible components that Statuspage represents.
  • Identify the communication owner and every applicable security, privacy, or legal owner who must approve public updates.
  • Confirm the formal security, privacy, legal, regulatory, contractual, and executive notification paths.

Steps

Work through the method

Use the listed inputs and tools. Check the evidence when you need to verify a step.

  1. Prepare phase templates

    Create investigating, identified, monitoring, and resolved templates. Each template must prompt for affected service, observed impact, confirmed facts, current action, and next-update time.

    Why it matters: Templates reduce drafting work while forcing the communication owner to insert current facts.

    Input
    The service catalogue, incident policy, and approved customer language.
    Output
    Reviewed phase templates with no fixed impact or repair claims.
    Tools in this stepAtlassian Statuspage

    Evidence for this step

  2. Publish the confirmed incident status

    Follow the formal incident-notification process first whenever it applies. Require approval from the communication owner and every applicable security, privacy, or legal owner before a public post. Then select the affected components, state the observed customer impact and current phase, and commit to a next-update time. Exclude hypotheses and sensitive security detail.

    Why it matters: Users receive one current account without consuming the technical lead’s time for duplicate replies.

    Input
    Confirmed facts from the incident lead and the appropriate phase template.
    Output
    A published incident update and a queued next-update reminder.
    Tools in this stepAtlassian Statuspage

    Evidence for this step

  3. Update through resolution

    After the required approvals, publish at the promised time even when the phase is unchanged. Move phases only on confirmed evidence, then state the restored service, monitoring state, and any approved follow-up when resolved.

    Why it matters: A reliable update rhythm preserves the status page as the current customer source.

    Input
    Incident-lead confirmations, monitoring evidence, and the published timeline.
    Output
    A complete incident timeline from first notice through resolution.
    Tools in this stepAtlassian Statuspage

    Evidence for this step

Success checks

Check the result before you finish

  • Every update identifies the affected service, observed impact, phase, and next-update time until resolution.
  • Published facts match the incident lead’s confirmed record.
  • Each public update records the communication approval and every applicable security, privacy, or legal approval.
  • Support responders link customers to one current incident page.
  • The resolved update distinguishes restoration from later analysis or follow-up.

Failure modes

Watch for these problems

  • The template contains a fixed impact statement. Replace it with a prompt for current confirmed facts.
  • A next-update time passes without new technical information. Publish that the investigation continues and set the next time.
  • The update exposes a vulnerability or customer data. Remove it and follow the security communication process.
  • The page says resolved before monitoring confirms restoration. Keep the incident in the appropriate current phase.

Tools

Choose the tools you need

Sources

Read the sources behind this practice

Check what each source supports and where the advice has limits.