Status Page Generator
Design and structure a public status page (status subdomain) with components, incidents, and subscriber channels tied to your monitoring stack.
Overview
Status Page Generator is an agent skill most often used in Operate (also Ship launch prep, Grow support) that structures a status subdomain, component health, and incident sections for customer-facing uptime communicatio
Install
npx skills add https://github.com/kostja94/marketing-skills --skill status-page-generatorWhat is this skill?
- Initial assessment for service components, monitoring feeds, audience, and hosting model
- Status page section map: overall status, per-component uptime, incidents, subscribe, uptime history
- Supports self-hosted or third-party hosts (e.g. Statuspage, Better Uptime)
- Pairs incident structure on the page with separate PR skill for external comms
- Reads project context from .claude or .cursor project-context.md when present
Adoption & trust: 726 installs on skills.sh; 586 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Customers cannot see whether your API or app is down, so you answer the same outage questions in support channels instead of pointing to a clear status source.
Who is it for?
Indie SaaS with multiple user-visible services who want a status.* page before or right after launch.
Skip if: Teams with no production traffic yet, internal-only tools with no external SLA, or full crisis PR workflows without a status site scope.
When should I use this skill?
User wants to create, optimize, or structure a status page or mentions status page, status subdomain, uptime, service health, incident page, or system status.
What do I get? / Deliverables
You get a concrete status page layout, component list, and hosting or monitoring integration plan; escalate narrative incident comms to public-relations when needed.
- Status page section outline
- Component and monitoring mapping
- Incident and subscription UX recommendations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Status pages are canonical in Operate because they communicate live service health and incidents to customers after you are in production. Monitoring is the primary shelf: the page reflects uptime tools and incident timelines, not one-off marketing copy.
Where it fits
Define status components and overall health states before public launch so early users know where to check during beta instability.
Wire Datadog or PagerDuty signals into a status page structure with incident timelines and subscriber notifications.
Reduce duplicate 'is it down?' tickets by publishing per-service uptime and maintenance windows on status.*.
How it compares
Use for page information architecture and uptime UX—not as a replacement for on-call runbooks or deep incident PR playbooks.
Common Questions / FAQ
Who is status-page-generator for?
Solo builders and small product teams running customer-facing APIs or apps who need a professional status page and subscriber-friendly incident history.
When should I use status-page-generator?
Use it in Operate when standing up monitoring-backed status communication; in Ship when preparing launch-trust artifacts; in Grow when reducing repetitive support tickets during degradations.
Is status-page-generator safe to install?
It is editorial and structural guidance only; review the Security Audits panel on this Prism page and avoid embedding secret webhook URLs in generated copy.
Workflow Chain
Then invoke: public relations
SKILL.md
READMESKILL.md - Status Page Generator
# 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: 1. **Service components**: API, dashboard, billing, etc. 2. **Monitoring**: What tools feed status (PagerDuty, Datadog, etc.) 3. **Audience**: Customers, developers, internal 4. **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