After shipping fast (the engine, eight monitor types, a dashboard, and backups), we stopped for a deliberate code-quality pass. Three passes, actually, shipped as 14 small PRs merged the same day.
Hardening, not just style#
Import atomicity. You can seed a self-hosted instance from hosted ObserveOne: run obs export from the ObserveOne CLI to produce a snapshot, then import the bundle into oo-workers. That bulk write runs inside a single transaction, so a crash partway through rolls back cleanly rather than leaving a half-populated instance.
Heartbeat endpoint. A heartbeat ping arrives at a public token URL, so the endpoint is hardened accordingly: pings are debounced, valid and invalid tokens get the same response, and only POST records a ping, so a GET link preview does nothing.
List query bounds. Incident, status-page, and API-key listings cap at 500 rows, which bounds memory on long-lived instances.
Scheduler stall surfacing. On a sustained database or Redis outage, a counter tracks consecutive failed ticks and raises a loud stall warning, with a recovery log on the first healthy tick, so an outage announces itself instead of going unnoticed.
The big split#
server.ts had grown to 1769 lines. The audit split it into a 150-line orchestrator plus 14 per-resource route files, handlers moved verbatim. Settings, backup, dialogs, and incidents got the same treatment. No behavior changed, the files just got small enough to hold in your head.
Why schedule a pass#
Shipping fast accrues debt you stop seeing. A scheduled pass is permission to harden the paths nobody would file a ticket for. Doing it as 14 small PRs kept every change reviewable and revertable, instead of one giant cleanup PR no one can read.