What it does
Takes the raw timeline of an outage (when monitoring detected it, when the team noticed, when it was resolved) and the root cause, then produces a short customer-facing status update and a separate, more detailed internal post-mortem covering impact, root cause, and concrete follow-up actions.
Install
This skill isn't packaged in an installable registry. It's a plain SKILL.md file you can copy directly. Copy it from the SKILL.md tab and save it at the path for your assistant:
Use it in your AI assistant
Claude Code
.claude/skills/uptime-incident-reporter/ (or ~/.claude/skills/uptime-incident-reporter/ for all projects)
GitHub Copilot (VS Code)
.github/skills/uptime-incident-reporter/
OpenAI Codex
.codex/skills/uptime-incident-reporter/
Cursor
.cursor/skills/uptime-incident-reporter/ (or ~/.cursor/skills/uptime-incident-reporter/ globally)
Compatibility
Any WordPress site; works from uptime monitor logs, host status pages, or a manual timeline supplied by the user.
The complete SKILL.md for this skill:
---
name: uptime-incident-reporter
description: Use when a site had downtime and the user needs a status page update, a customer-facing incident summary, or an internal post-mortem written up.
---
# Uptime Incident Reporter
## When to use
A downtime incident just happened or was just resolved, and the user needs both a short public-facing update and a more thorough internal write-up, without spending time drafting either from scratch.
## Procedure
1. Gather the raw timeline: when the outage started, when monitoring or users first detected it, when the cause was identified, and when service was restored.
2. Confirm the root cause in plain terms (server resource exhaustion, plugin conflict, hosting outage, DNS issue) rather than technical jargon for the public version.
3. Draft a short customer-facing status update: what happened, impact window, current status, and whether any customer data was affected.
4. Draft a longer internal post-mortem: detailed timeline, root cause, contributing factors, what went well in the response, and specific follow-up actions with owners.
5. Keep the customer-facing version free of internal specifics (server names, vendor details, blame) and keep the post-mortem blameless, focused on process gaps, not individuals.
6. Flag any follow-up action that involves infrastructure or code changes as needing separate review before implementation.
## Guardrails
- Never state a root cause as confirmed in the customer-facing update if it's still under investigation, say "under investigation" rather than guessing to sound more authoritative.
- Do not include internal-only details (specific server credentials, vendor contract terms, individual staff names in a blaming tone) in anything meant for external or customer distribution.