Statuspage

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a status page that replaces Statuspage — and read the first rule, because it is the only one that really matters.

Read this first: the value of a status page is entirely that it works when nothing else does. A status page hosted on the infrastructure it reports on is decoration. Deploy it on a different machine, at a different provider, on a different network, and preferably serve it as static files. Everything below assumes that.

STACK
- Node 20+ with Fastify for the admin and the API
- SQLite through better-sqlite3, WAL mode
- The public page rendered as static HTML on every change and served by Caddy directly, so the page survives the application being dead
- Caddy in front

THE DATA MODEL
- pages: id, slug, name, custom_domain, logo_path, accent, timezone, support_url, is_public, password_hash
- components: id, page_id, group_name, name, description, position, status, status_since — operational, degraded, partial outage, major outage, under maintenance
- component_history: id, component_id, status, from_at, to_at — append-only, and what every uptime figure is computed from
- incidents: id, page_id, title, impact, status, started_at, resolved_at, is_scheduled, scheduled_start, scheduled_end, components_json
- incident_updates: id, incident_id, body_md, status, created_by, at — append-only. An incident is a sequence of updates and a published update is never edited, only followed by another
- subscribers: id, page_id, kind, target, token, confirmed_at, unsubscribed_at, components_json — email, webhook, RSS
- notifications: id, incident_update_id, subscriber_id, sent_at, error — one row per person per update, so nobody is told twice
- metrics: id, page_id, name, source, unit, is_public; metric_points: metric_id, value, at

THE PUBLIC PAGE
- One banner at the top: everything operational, or the current worst state, in words a customer understands
- Components grouped, each with its state and 90 days of history as one bar per day
- Uptime percentage with its window and its definition written next to it. Everybody computes uptime differently and a number without a definition is decoration
- Open incidents at the top with their update history newest first, each timestamped in the reader's own zone with the original zone shown
- Scheduled maintenance announced in advance and shown before it starts
- Optional public metrics — response time, queue depth — as small charts
- Static, under 50KB, no framework, works on a phone. Everybody loads it at once, precisely when things are going wrong
- Regenerated on every change and on a schedule, so the newest state is on disk even if the admin process is down

WRITING AN INCIDENT
- Templates for the common shapes, because nobody writes well at three in the morning. Investigating, identified, monitoring, resolved — each with a skeleton to fill
- The first update should go out within minutes and say almost nothing except that you know. That is what customers want: acknowledgement, not diagnosis
- Impact chosen deliberately: none, minor, major, critical
- Components attached to the incident, and their status set from it in one action
- A post-incident summary after resolution, which is a separate field and can be added later
- Nothing published is ever edited. A correction is a new update saying what was wrong. A status page that quietly rewrites its own history is worth nothing

NOTIFICATIONS
- Email, webhook, RSS and Atom. SMS only through a provider, and it is the one part with a real per-message cost — say so
- Per-component subscriptions, so somebody who only uses one part of the product is not paged about another
- Double opt-in, one-click unsubscribe with no login
- One row per subscriber per update, written before sending, so a crash mid-send resumes exactly and nobody is told twice
- The notification path must not depend on the same mail infrastructure as your product. If your product is down because your provider is down, your status emails will not go either — use a different sender for these

AUTOMATION
- An API to open, update and resolve an incident, and to set a component's state, so a monitor can act
- Automatic opening from a monitor is useful and dangerous: require confirmation from more than one check, and never let it write customer-facing prose. An automated incident sets a state; a human writes the words
- A webhook in as well as out, and a command-line tool, because the fastest path during an outage is a terminal that is already open

ACCESS
- The admin behind authentication and, ideally, reachable independently of everything else
- A private page option behind a password for internal or customer-specific status

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SMTP_URL, SESSION_SECRET, STATIC_OUTPUT_PATH
- Migrations on boot, each once
- Custom domain with on-demand TLS, checked against the pages table before a certificate is requested
- Nightly backup off the machine, restore script
- Health endpoint — and an external check on the status page itself, because the page nobody is watching is the page that is quietly broken

WHAT MATTERS MOST
Where it runs and static generation. Put it somewhere else entirely, render the page to disk, and then unplug the application and confirm the page still serves. If that does not work, nothing else here matters.

Give me the repository, the static generator, migrations, .env.example, the incident templates, the CLI, and a README whose first section is the independent deployment.