Writes customer-facing incident status updates for each lifecycle stage - investigating, identified, monitoring, resolved - with cadence rules and plain-language templates. Use when someone asks "write a status page update", "what do we tell customers about this outage", "draft the resolved notice", or during an active incident needing customer communication. Do NOT use for the internal post-incident analysis - use postmortem-writer once the incident is closed; for deciding severity and internal escalation flow use sev-triage; for summarizing an incident upward to executives use escalation-summary.
Click to play with sound.
---
name: Status Page Update
description: Writes customer-facing incident status updates for each lifecycle stage - investigating, identified, monitoring, resolved - with cadence rules and plain-language templates. Use when someone asks "write a status page update", "what do we tell customers about this outage", "draft the resolved notice", or during an active incident needing customer communication. Do NOT use for the internal post-incident analysis - use postmortem-writer once the incident is closed; for deciding severity and internal escalation flow use sev-triage; for summarizing an incident upward to executives use escalation-summary.
---
# Status Page Update
Customers do not need the stack trace. They need to know what is broken, whether the team knows about it, and when it will be fixed. Every update earns trust or burns it - and the two fastest ways to burn it are silence (no post while customers are clearly affected) and a premature "resolved" that gets reopened. This skill produces updates that are fast, honest, specific about scope, and never blame anyone.
## Inputs to collect
Before writing any update, get:
1. **The observable symptom** - what customers actually experience, in their terms ("API requests returning 500s"), not internal terms ("the ingest shard is degraded").
2. **The affected scope** - which customers, which region, which feature. "Customers using API key authentication in us-east-1," never "some customers."
3. **The stage** - investigating, identified, monitoring, or resolved. The stage dictates the template and what may be promised.
4. **Timestamps** - incident start, and the timezone convention (UTC with label, or the user's timezone).
5. **The cause in plain language** - only for identified and later; never speculate before then.
## Cadence rules
Cadence is as load-bearing as the words:
- **First post within 15 minutes** of confirming customer impact. A late first post reads as "they didn't know."
- **Updates every 30-60 minutes** while the incident is active - 30 for SEV1, 60 acceptable for lower severities.… load the full skill through Skill Me