阅读中文版本

Status Page Update Workflow

Maintain an accurate public status page during an incident with clear components, impact, and a regular update cadence.

Overview

Keep the public status page accurate and regularly updated during incidents.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

• A status page tool
• Component mapping for dependencies
• An update cadence

Procedure

1. Map impact to components

Select the status page components that correspond to the affected functionality.

Expected state: The status page reflects which components are impaired.

2. Set the status and impact

Mark the affected components as degraded or major outage with a plain-language impact.

Expected state: Visitors understand what is affected without jargon.

3. Update on a cadence

Post updates at a regular interval even when little changes.

Expected state: The page never goes silent and misleading.

4. Resolve and postmortem-link

Mark components operational again and link any public postmortem.

Expected state: Subscribers get closure and further context.

statuspage update --component checkout --status degraded --body 'Some checkouts failing'

Verification

Confirm affected components matched the real impact, updates met the cadence, and resolution was posted.

Decision points

Update only on changes or on a cadence?

• Cadence plus changes
• Only when something changes

Recommendation: Update on a cadence so silence is not read as resolution.

Technical or plain language?

• Plain language with component names
• Internal terminology

Recommendation: Use plain language so customers can judge the impact themselves.

Common failures

• Silent status pages push load to support.
• Wrong component mapping misleads customers.
• Jargon prevents customers from judging impact.