Status app

1. Copy config/systems/_template.ts to config/systems/<id>.ts.
2. Fill in the documentation and the monitors.
3. Add one line to config/systems/index.ts.

That is the whole procedure. The dashboard, the per-system page, the cron, the uptime maths and the public JSON API all pick it up with no further changes. Monitor ids must be unique across all systems — they are the storage keys — and the registry validates that at import time.

/api/cron/check runs every enabled monitor in parallel, classifies each result as up / degraded / down, writes the run to Upstash, and opens or closes an incident when the status flips. The request is rejected unless it carries CRON_SECRET.

A page view never probes directly. What it can do is notice the stored data has gone stale and schedule a sweep after the response is sent — so looking at the board can refresh it, but never slows it down, and the numbers on screen are always the ones that were measured.

Vercel's Hobby plan allows exactly one cron a day, which is a report, not a health check. Three layers cover it, in increasing order of reliability:

1. Vercel Cron, daily, from vercel.json. It is the floor, and it is what Hobby permits.
2. Stale-triggered sweeps. Opening the dashboard or calling GET /api/health refreshes the

data in the background when the last sweep is older than SWEEP_STALE_AFTER_MINUTES (10 by default). A short lock in Upstash means ten people opening the page cause one sweep between them, not ten.

1. A GitHub Actions heartbeat at .github/workflows/status-sweep.yml, every 10 minutes,

calling the same endpoint with the same secret. The repository is public, so those minutes are free. It needs two repository secrets: STATUS_URL and CRON_SECRET.

Layer 2 alone keeps the board honest for anyone looking at it. Layer 3 is what catches an outage while nobody is looking, which is the only reason a status page exists. On a Pro plan, set the real schedule in vercel.json and delete the workflow.

Upstash Redis over its REST API, which works from any runtime:

• atrium:monitor:{id}:last — the most recent run
• atrium:monitor:{id}:runs — a capped list used for uptime and the sparklines
• atrium:incident:{monitorId} — the currently open incident, when there is one
• atrium:incidents:log — closed incidents, newest first

Without Upstash credentials the app falls back to an in-memory store so local development works unconfigured. That store is per-process and disappears on restart, which is fine locally and useless in production — the deployment must have the credentials.

The repo view runs turbo to typecheck, lint, test and build workspaces on demand. That cannot work on Vercel — there is no toolchain and no working tree in a serverless function — so those endpoints refuse outside development. The deployed app shows the snapshot committed by bun run checks:snapshot instead, with the commit and timestamp it came from.