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.

Never publish a speculative resolution time

Do not state or estimate when the incident will be fixed. No "we expect this resolved by 3pm," no "should be back within the hour," no "ETA 30 minutes." A missed estimate erodes trust more than silence does, and resolution time during an active incident is genuinely unknown.

What you may commit to instead is the next update time — a cadence you control, e.g. "next update in 30 minutes" or "we will post again within the hour." That is a promise about your communication, not about the fix. Provide one on every non-Resolved post.

Tone and content

• Plain and factual. One apology at most; do not repeat it every post.
• No internal jargon, service names, or ticket numbers the customer cannot use.
• No blame — not a vendor, not a team, not a person. State the effect, not the culprit.
• Do not disclose security-sensitive detail (exploit specifics, attacker behavior) in a

public post while an incident is active.

Shape of a post

1. Lifecycle label.
2. Impact — who is affected, what they cannot do (confirmed scope only).
3. Workaround, if one exists.
4. One line on current status/action, in customer terms.
5. Next update time (omit only on Resolved).