---
name: customer-status-page-writer
description: Draft customer-facing status-page updates during an incident — initial post, progress updates with severity-appropriate phrasing, ETA hedging, resolution post, and post-incident summary.
version: 1.0.0
author: VantagePoint Networks
author_url: https://www.vpnetworks.co.uk
audience: Incident Commanders, Comms Leads, Customer Success Managers, MSPs running status pages, anyone with a Statuspage / Instatus / Atlassian Status feed
output_format: Formatted Markdown pack with initial / investigating / identified / monitoring / resolved templates, severity tone guidance, FAQ for common edge cases, and a resolution summary.
license: MIT
last-reviewed: 2026-04
---

# Customer Status Page Writer

A Claude Code skill for the person writing status-page updates at 3am — honest, appropriately hedged, professional, neither over-reassuring nor panic-inducing.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/customer-status-page-writer`. Describe the incident. Answer the clarifying questions. Receive the update pack.

## When to use this

- An incident has started and you need an initial status post in 5 minutes.
- You need to post an update but nothing new has happened ("still investigating") without it sounding vacuous.
- You've identified the root cause and need to explain it at a customer-appropriate level.
- You're about to declare resolution and want the language right.
- You want a template set saved for future incidents so nobody has to draft under pressure.

## What you'll get

A single Markdown document containing:

- **Status lifecycle posts** following the standard Statuspage / Instatus stages:
  - Investigating (initial)
  - Identified (cause known, fix in progress)
  - Monitoring (fix deployed, watching)
  - Resolved (closed)
- **Severity tone guidance** (minor / degraded / major / outage)
- **ETA hedging patterns** ("we expect updates at X" vs "estimated restoration")
- **Scheduled-maintenance** variants (pre-announcement, starting, completed)
- **Post-incident summary** (one-paragraph public version; detail lives in a separate PIR)
- **Common-edge-case phrasing** (partial impact, slow recovery, rolling back, intermittent)

## Clarifying questions I will ask you

1. **What's the service name customers call it?** (what they look for on the status page)
2. **What's the user-visible symptom right now?**
3. **Severity in your grading?** (minor / degraded / major / full outage)
4. **Geographic / tenant / plan scope?** (all customers, EU region, free tier, specific customer)
5. **Have you identified the cause?** (yes / no / partially)
6. **Estimated time to restore?** (if any — be honest)
7. **Has the customer taken an action that could have triggered this?** (affects phrasing)
8. **Third-party / upstream issue?** (name the provider, or "our infrastructure provider")
9. **Regulatory angle?** (financial-services customer, data involved)
10. **Tone target?** (reassuring, neutral, apologetic, urgent)

## Output template

```markdown
# Status Page Update Pack — <incident ref>

**Service:** <service name> · **Severity:** <minor / degraded / major / outage>

## 1. Investigating (initial — post within 5 minutes of detection)

**Title:** Investigating <service> <issue>
**Body:**
> We're investigating reports of <user-visible symptom> affecting <scope>. Our team is engaged and we'll post an update within 30 minutes. Apologies for the disruption.

**When to use:** you don't know the cause yet, you're not sure how bad it is, and you must acknowledge.

## 2. Identified (cause known, fix in progress)

**Title:** Identified cause of <service> <issue>
**Body:**
> We've identified the cause of the <issue> affecting <scope>. <One-sentence customer-appropriate explanation — e.g. "A configuration change to our authentication service introduced an error affecting sign-ins."> Our team is rolling out a fix. We'll update this page within <N> minutes.

**Hedging rule:** if restoration ETA is < 30 min, commit to it. If > 30 min, say "our team is working to restore service; next update in <N> minutes" rather than a specific ETA.

## 3. Monitoring (fix deployed, watching)

**Title:** Monitoring recovery of <service>
**Body:**
> A fix has been deployed and <service> is recovering. We're monitoring closely to confirm full restoration. If you continue to see <symptom>, please <contact / retry>. We'll confirm resolution within <N> minutes.

## 4. Resolved (close the incident)

**Title:** Resolved — <service> <issue>
**Body:**
> As of <time UTC> <service> is fully restored. The root cause was <one-sentence public-safe summary>. We apologise for the impact. A post-incident summary will be published within <N> working days.

**Post this when:**
- All affected customers confirmed or metrics show full recovery for <N> minutes
- You're willing to defend the claim if a customer reports it's still broken

## 5. Severity Tone Guidance
| Severity | Tone | Language style | Example opener |
|---|---|---|---|
| Minor | Matter-of-fact | Short, no drama | "A small number of customers..." |
| Degraded | Acknowledging | Clear about scope | "Some users may experience slower..." |
| Major | Apologetic but composed | Direct, specific | "We are currently experiencing..." |
| Full outage | Direct, urgent | Short, no euphemism | "<Service> is currently down..." |

Avoid: "inconvenience," "hiccup," "glitch" — all read as minimising.

## 6. ETA Hedging Patterns
| Situation | Language |
|---|---|
| You know the fix is minutes away | "We expect service restored within <N> minutes" |
| Fix is deploying but validation pending | "We're monitoring recovery and expect full restoration shortly" |
| Duration genuinely unknown | "Our team is working on this. Next update at <specific time>." |
| Upstream provider issue, no ETA they've given | "We're dependent on <provider> to restore <component>. We'll update as soon as we hear from them." |
| Partial degradation only | "<Function X> is affected. <Function Y> is operating normally." |

## 7. Scheduled Maintenance (the friendly kind)

### Pre-announcement (24-72h before)
**Title:** Scheduled maintenance — <service> — <date>
**Body:**
> We'll be performing maintenance on <service> on <date> from <start — end> UTC. During this window, <specific impact — e.g. "sign-ins may briefly fail and writes will be queued"> for up to <N> minutes. No action required on your part. Thank you for your patience.

### Starting
**Title:** Maintenance starting — <service>
**Body:**
> The scheduled maintenance window for <service> is now starting. Expected duration: <N> hours. We'll post an update when complete.

### Completed
**Title:** Maintenance completed — <service>
**Body:**
> The scheduled maintenance for <service> is complete as of <time>. All systems are operating normally. Thank you for your patience.

## 8. Edge-Case Phrasing

### Intermittent issues
> "Some users are experiencing intermittent <symptom>. We're gathering diagnostic data and will post an update within 30 minutes. If you're affected, a refresh / retry is likely to succeed."

### Slow recovery
> "<Service> is recovering but some backlog remains. You may see delayed <X> for up to <N> minutes as processing catches up."

### Rolling back
> "We've taken the decision to roll back the recent change to restore service. Stability is our priority. We'll investigate and attempt the change again after additional testing."

### Third-party caused
> "<Service> is impacted by an issue at our infrastructure provider. We're in contact with their support team and will relay updates here."
> (Name or don't-name is a business decision. If you name, be accurate. "Our cloud provider" is acceptable.)

### Don't-know-what-it-is-yet
> "We're seeing unusual <symptom> affecting <scope>. Our team is investigating and we'll share more as we know it. Next update at <specific time>."

### Customer-action triggered (rare, but honest)
> "We've identified that a recent customer configuration change triggered <symptom>. Guidance on resolving this has been emailed to affected accounts. For others: no action needed."

## 9. Post-Incident Summary (published within 5 working days)

**Title:** Post-incident summary — <service> <date>
**Body (one paragraph, public-safe):**
> On <date>, <service> experienced <incident> affecting <scope> for <duration>. The root cause was <specific but non-sensitive — e.g. "a change to our authentication service that failed under specific query patterns we hadn't tested for">. During the incident, <mitigation/rollback action>. Service was fully restored at <time UTC>. To prevent recurrence, we've <specific changes — e.g. "added test coverage for the affected query patterns and implemented a graduated rollout for future authentication changes">. We apologise to affected customers.

**Not in this summary:**
- Internal stack traces
- Individual engineer names
- Customer-identifiable data
- Contractual figures

## 10. Things Never To Write
- "A small glitch" (for anything lasting > 5 min)
- "All systems are now fully operational" (say it when it's true, not before)
- "We are committed to..." (empty)
- Anything that blames a named individual
- Anything that speculates without evidence
- ETAs you can't meet
```

## Example invocation

**User:** "Our SaaS CRM went down 14:00 UK time, appears to be a database issue, affects all customers, still investigating cause. Need initial status post now."

**What the skill will do:**
1. Ask the 10 questions quickly, pressing on: is the outage confirmed full-stop or partially degraded (determines severity), are there customers in regulated sectors who may need direct comms.
2. Produce the Investigating post immediately: severity "outage", tone direct, short opener, commitment to next update at 14:30 UK.
3. Prepare the Identified draft (blank for now) and the Monitoring draft structure so the Comms Lead can drop in details as the incident progresses.
4. Note that, once resolved, the public-safe root cause needs care (say "a database connectivity issue" not "a corrupted primary replica").
5. Flag that if the incident exceeds 30 minutes, a targeted email to the top-20 client accounts is often warranted in addition to the status page.

## Notes for the requester

- **Honesty beats reassurance.** "We don't know yet, next update in 30 minutes" is better than "everything's under control" when it isn't.
- **Specific times, always.** "Soon" is meaningless. "14:30 UTC" is useful.
- **Never say "all systems operational" until you've verified for all customers for at least 10 minutes.**
- **A public post-incident summary should be short, specific, and forward-looking.** Detail goes in the internal PIR, not on the status page.
- **Don't name engineers.** Don't name customer contacts. Don't attribute internally.
- **Good looks like:** customers on your status page can tell within 15 seconds: what's affected, how bad, when we'll know more. Their support burden goes DOWN, not up, during the incident.

---
*VantagePoint Networks · <https://www.vpnetworks.co.uk> · Authored by Hak · Free under the MIT licence*