Pages: Status Page
Guides status page design for communicating service health, uptime, and incidents. Typically at status.* subdomain. Reduces support during outages, builds trust.
When invoking: On first use, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On subsequent use or when the user asks to skip, go directly to the main output.
Initial Assessment
Check for project context first: If .claude/project-context.md or .cursor/project-context.md exists, read it for product and service components.
Identify:
- Service components: API, dashboard, billing, etc.
- Monitoring: What tools feed status (PagerDuty, Datadog, etc.)
- Audience: Customers, developers, internal
- Hosting: Self-hosted vs. third-party (Statuspage, Better Uptime, etc.)
Status Page Structure
| Section |
Purpose |
| Overall status |
Operational, Degraded, Outage, Maintenance |
| Components |
Per service: status, uptime % |
| Incidents |
Active and past; timeline, updates |
| Subscribe |
Email, SMS, RSS for notifications |
| Uptime history |
90-day or custom range (optional) |
Best Practices
Communication
- Clear status: Operational, Degraded, Partial Outage, Major Outage
- Incident updates: Timely, honest, actionable
- Post-mortem: Link to post-incident review when public
- Maintenance: Schedule ahead, notify subscribers
Design
- Scannable: Status at a glance; green/yellow/red
- Mobile: Critical for on-the-go checks
- Accessible: Color + text; don't rely on color alone
- No login required: Public status, no auth
Technical
- Independent hosting: Status page should stay up when main product is down
- Subdomain: status.yourdomain.com
- Integrations: Slack, PagerDuty, etc. for incident creation
- Historical data: Uptime %, incident count
Output Format
- Structure (components, incident format)
- Status definitions and colors
- Incident template (title, updates, resolution)
- Subscribe options
- Hosting recommendation (self vs. third-party)
Related Skills
- docs-page-generator: Link status from docs footer
- api-page-generator: Link status for developer trust
- footer-generator: Status link in footer
- 404-page-generator: Status page as utility; similar UX principles
1---
2name: status-page-generator
3description: When the user wants to create, optimize, or structure a status page. Also use when the user mentions "status page," "status.yourdomain.com," "uptime," "service health," "incident page," or "system status." For incident comms, use public-relations.
4metadata:
5 version: 1.0.1
6---
7
8# Pages: Status Page
9
10Guides status page design for communicating service health, uptime, and incidents. Typically at `status.*` subdomain. Reduces support during outages, builds trust.
11
12**When invoking**: On **first use**, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On **subsequent use** or when the user asks to skip, go directly to the main output.
13
14## Initial Assessment
15
16**Check for project context first:** If `.claude/project-context.md` or `.cursor/project-context.md` exists, read it for product and service components.
17
18Identify:
191. **Service components**: API, dashboard, billing, etc.
202. **Monitoring**: What tools feed status (PagerDuty, Datadog, etc.)
213. **Audience**: Customers, developers, internal
224. **Hosting**: Self-hosted vs. third-party (Statuspage, Better Uptime, etc.)
23
24## Status Page Structure
25
26| Section | Purpose |
27|---------|---------|
28| **Overall status** | Operational, Degraded, Outage, Maintenance |
29| **Components** | Per service: status, uptime % |
30| **Incidents** | Active and past; timeline, updates |
31| **Subscribe** | Email, SMS, RSS for notifications |
32| **Uptime history** | 90-day or custom range (optional) |
33
34## Best Practices
35
36### Communication
37
38- **Clear status**: Operational, Degraded, Partial Outage, Major Outage
39- **Incident updates**: Timely, honest, actionable
40- **Post-mortem**: Link to post-incident review when public
41- **Maintenance**: Schedule ahead, notify subscribers
42
43### Design
44
45- **Scannable**: Status at a glance; green/yellow/red
46- **Mobile**: Critical for on-the-go checks
47- **Accessible**: Color + text; don't rely on color alone
48- **No login required**: Public status, no auth
49
50### Technical
51
52- **Independent hosting**: Status page should stay up when main product is down
53- **Subdomain**: status.yourdomain.com
54- **Integrations**: Slack, PagerDuty, etc. for incident creation
55- **Historical data**: Uptime %, incident count
56
57## Output Format
58
59- **Structure** (components, incident format)
60- **Status** definitions and colors
61- **Incident** template (title, updates, resolution)
62- **Subscribe** options
63- **Hosting** recommendation (self vs. third-party)
64
65## Related Skills
66
67- **docs-page-generator**: Link status from docs footer
68- **api-page-generator**: Link status for developer trust
69- **footer-generator**: Status link in footer
70- **404-page-generator**: Status page as utility; similar UX principles
kostja94