Instatus

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 Instatus: it tells my customers what is broken, before they email me to ask.

STACK
- Node 20+ with Fastify, server-rendered HTML, no client framework
- SQLite through better-sqlite3, WAL mode
- The public page served as static HTML regenerated on every change, so it stays up when the app behind it does not
- Caddy in front, and the page hosted from a different machine or provider than the thing it reports on

THE DATA MODEL
- components: id, name, description, group_name, position, status, is_public
- incidents: id, title, status, impact, started_at, resolved_at, is_scheduled, scheduled_for, scheduled_until
- incident_updates: id, incident_id, body, status, created_at — the timeline, append-only
- incident_components: incident_id, component_id, status_during
- checks: id, component_id, kind, target, interval_seconds, timeout_ms, expected
- check_results: id, check_id, ok, latency_ms, status_code, error, checked_at
- subscribers: id, email or webhook_url, verified_at, unsubscribed_at, scope
- Component status: operational, degraded, partial outage, major outage, maintenance
- Incident status: investigating, identified, monitoring, resolved

THE PUBLIC PAGE
- Current state at the top in one line — all systems operational, or the worst thing that is true
- Every component with its own state, grouped
- Ninety days of history as a bar per day per component, coloured by the worst state that day
- Open incidents in full, with their updates newest first and the time between them visible
- Past incidents by month, with total downtime per component
- Uptime percentage per component over 7, 30 and 90 days. State the formula on the page: minutes not in a degraded or outage state, over minutes in the window
- No login, no cookie, no third-party script. It must load in under a second on a phone on a train

MONITORING
- Checks that run themselves: HTTP status and latency, a keyword present or absent in the body, TCP port open, TLS certificate expiry, and a heartbeat a cron job pings
- A component goes degraded after N consecutive failures, not the first one, and N is configurable per check
- Recovery needs the same N in a row, so a flapping service does not spam
- A failed check opens an incident automatically if the admin turned that on, with a title generated from the component and the failure
- Never let the monitor be the reason the page is wrong: a check that has not run in twice its interval shows as unknown rather than as fine

TELLING PEOPLE
- Subscribe by email, by webhook, by RSS, and by Slack incoming webhook
- Confirm an email address before sending anything to it
- One message when an incident opens, one per update, one when it resolves — never more
- Per-component subscriptions: somebody who only uses the API does not want the dashboard's outages
- Every email has one-click unsubscribe that works without logging in

THE ADMIN
- Open an incident in one field: a title, then updates as you learn things
- Templates for the three sentences you always write
- Scheduled maintenance in advance, shown on the public page before it starts and announced by email
- Backdate an incident: real outages get written up afterwards, and a status page that cannot record the past is a status page that lies about uptime
- Every change to an incident kept, never edited in place

RESILIENCE, WHICH IS THE WHOLE POINT
- The public page is a static file. If the admin, the database or the monitor dies, the last known state is still being served
- Regenerate on every change, and once a minute regardless
- No dependency on the systems being reported on: no shared database, no shared network, no shared provider
- Say in the README that hosting this next to the product it reports on defeats the exercise

THE INTERFACE
- The public page: one column, big type, no marketing copy, no cookie banner
- The admin: a list of components, a list of incidents, and a form. Nothing else
- Dark and light, and a light-on-white default because status pages are read on projectors in offices

OPERATIONS
- .env: DATABASE_PATH, SMTP_URL, BASE_URL, ADMIN_PASSWORD_HASH, SLACK_WEBHOOK
- Migrations on boot, one at a time, recorded
- Nightly backup with off-server upload, plus restore
- Prometheus-style metrics endpoint, so the thing that watches this can be watched

WHAT MATTERS MOST
Build the public page and the incident timeline first, and make the page a static file from the first commit. Automatic monitoring is a nice second act; a page that goes down with the product is worse than no page at all.

Give me the repository, migrations, .env.example, a seed with three components, and a README with deploy steps for a small VPS in a different region from the main product.