v0.14.0 — Uptime Kuma integration

Spinup meets your monitoring: vanity pages become health endpoints any uptime tool can watch, and with an Uptime Kuma connection the monitors set themselves up — load graphs, dead-man's-switch heartbeats, sparklines in the Health view, and maintenance windows around reboots.

Highlights

• Vanity pages double as health endpoints. The page the V wizard seeds now answers ?healthz — plain 200 ok, or 503 when 1-min load per core tops 2 or disk free drops under 10% — so any plain HTTP monitor gets resource alerting from the status code alone. ?format=json&key=… serves full metrics (load, cores, uptime, disk, memory, PHP version) behind a per-site key generated at seed time. Tool-agnostic by design; recipes in docs/uptime-kuma.md.
• Site monitoring (m). Press m on a site to wire it into your own Uptime Kuma (one-time connect with a real login check; 2FA supported — the code is asked exactly once, then a stored token covers every later session). Vanity sites get the full treatment: a healthz monitor plus a load push monitor fed by a once-a-minute cron — Kuma graphs server load, and a silent cron (server down, cron dead, egress broken) flips the monitor. Regular sites get a homepage monitor with cert-expiry alerts; client site files are never touched. R refreshes an existing vanity page to the current version — with or without Kuma.
• The V wizard registers monitors automatically. With Kuma connected, two new steps after publishing the page: register both monitors, install the heartbeat cron. They auto-skip when Kuma isn't set up, and a monitoring failure is skippable — the site is already live.
• Kuma status flows back into Spinup. A Monitor row per site in Details, a ▼ N monitors down header badge (silent when all's well), and a Monitor panel in the Health view (h) with 24h uptime, response-time and server-load sparklines — real history that survives reopening the view.
• Reboots never page you. Firing a reboot first wraps the server's monitors in a Kuma maintenance window and removes it when the reboot settles. Strictly best-effort: Kuma being unreachable never blocks the reboot.

Notes

• Monitors are adopted, not duplicated: same-named monitors in Kuma are reused, a hand-made push monitor keeps its token, and recorded ids are re-verified against Kuma before being trusted (deleting a monitor there and pressing a re-creates it).
• Load pushes are sent ×100 as integers (some Kuma builds silently drop float pings); Spinup's views scale them back.
• Connection lives in config.json (0600) or via SPINUP_KUMA_URL / _USERNAME / _PASSWORD. Speaks Kuma's socket.io API; handles both 1.x and 2.x monitor schemas. Dev Mode never touches a real Kuma.
• New dependency: socket.io-client — run bun install after updating.

Update: press u in ? Help, or git pull in your checkout, then bun install (one new dependency). The global spinup symlink picks it up immediately.

Full changelog: v0.13.0...v0.14.0