Incident Status-Page Update

Incident Status-Page Update

The public update a company posts to its status page during an incident. Base models default to an apologetic paragraph that leads with a cause or an apology, buries who is affected, and volunteers a made-up "we expect this resolved within the hour." A status page has a different job: tell affected customers what is broken, what they can do right now, and where the fix stands — without promising a time no one can keep.

Every update is one post in a running thread and carries exactly one lifecycle label.

Lead with impact, then workaround

The first line states who is affected and what they cannot do, in the customer's terms — not the internal cause, not an apology. "Customers in the EU region cannot log in" comes before any mention of a database or a deploy.

If a workaround exists, it goes immediately after impact, before anything else. A customer who can keep working via a workaround is the whole point of the update; do not bury it under status-history detail.

State only impact you have confirmed. If scope is still unknown, say it is under investigation rather than guessing at a number.

Pick exactly one lifecycle label

Every post declares which of the four states the incident is in. Move forward through them; never skip back to an earlier state in a later post.

• Investigating — the problem is confirmed and you are still finding the cause. Use when you know something is wrong and are diagnosing.
• Identified — you know the cause and a fix is in progress. Use once the root cause is understood, even if the fix is not deployed yet.
• Monitoring — the fix is applied and you are watching to confirm recovery. Use after deploying the fix but before you are certain it held.
• Resolved — service is fully restored and confirmed stable. Use only when the incident is genuinely over, not when a fix is merely deployed.

Do not mark an incident Resolved while you are still watching it — that is Monitoring. Resolved is a claim that it is over.