Should you build your own Instatus?

Build a self-hosted status page app in an empty folder. Stack, no substitutions: Node 20, Fastify, better-sqlite3, server-rendered HTML via Fastify's reply.type('text/html') and plain template literal functions, vanilla CSS in one file. No React, no build step, no ORM.

What it does:
1. Public page at / showing a list of components (name, description, status: operational, degraded, partial_outage, major_outage) with an overall banner computed from the worst component status.
2. Under that, incidents newest first. An incident has a title, impact, current status (investigating, identified, monitoring, resolved), and an append-only list of timestamped updates.
3. A 90 day uptime strip per component rendered from a daily_status table (one row per component per day, worst status seen that day). Fill it from the poller below.
4. GET /api/status returning the same data as JSON, and GET /feed.rss as a valid RSS 2.0 feed of incident updates.
5. Admin at /admin behind a single bearer token from ADMIN_TOKEN in .env, checked with a constant-time compare. Forms to: set component status, open an incident, append an update, resolve it. HTML forms, no JS framework.
6. Subscribers: POST /subscribe takes an email, stores it unconfirmed with a random token, emails a confirm link. GET /confirm/:token confirms. Every email includes a working GET /unsubscribe/:token link. When an admin appends an incident update, queue one email per confirmed subscriber and send them sequentially with a small delay, logging failures to a sends table. Use Resend via fetch with RESEND_API_KEY from .env; if the key is absent, write the emails to ./outbox/ as .txt files instead so it runs offline.
7. Optional poller: a setInterval that HTTP GETs each component's check_url if set, marks degraded on slow responses over 2s and major_outage on non-2xx or timeout, and writes daily_status.

In scope: SQLite schema created on boot with migrations as plain SQL strings, seed script with three components and one resolved incident, a README that says in one sentence to deploy this somewhere other than the infrastructure it monitors.

Out of scope, do not build: multi-tenancy, SMS, Slack or Discord integrations, OAuth, custom domain automation, an analytics or telemetry call of any kind, Docker, a JS bundler.

Secrets only in .env, with a .env.example committed and .env gitignored. Include npm scripts: dev, seed, poll. It must run with npm install and npm run dev on a clean machine.