---
name: incident-status-comms
source: https://app.decimal.ai/s/incident-status-comms@1/SKILL.md
source_sha256: bf0da56fd2b4
---

# 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**).