feat: correlate server errors and monitor application health

docs/OPERATIONS.md

@@ -43,3 +43,31 @@ before reopening access. Discord images already posted are separate from app dat
 Verification: `bun test src/ops/backups.test.ts` exercises WAL progress, restored
 content, revoked sessions, replicas, retention, missing storage, and refusal to
 overwrite an existing destination.
+
+## Monitoring
+
+Every API response includes a server-generated `X-Request-ID`. Unexpected errors
+return that reference to the browser and write a JSON `request_failed` event to
+stderr with the request ID, method, route template, error type, and stack locations.
+Error messages, SQL values, request bodies, cookies, and query strings are omitted
+so credentials and habit content do not enter logs. Production source maps in
+`dist/` help map stack locations back to the source. Backup outcomes also emit
+`backup_completed` and `backup_failed` events.
+
+`GET /api/health` checks SQLite and returns 503 if enabled automatic backups are
+failing or have never succeeded. It returns no account data, paths, or credentials.
+Run the health monitor independently of the application process:
+
+```sh
+bun run monitor --once
+bun run monitor
+```
+
+`MONITOR_URL` defaults to `http://127.0.0.1:$PORT/api/health`. For an outside-in
+check, run the monitor on another machine and set it to the public HTTPS endpoint.
+The one-shot command exits nonzero on failure. Continuous mode checks every minute,
+times out after ten seconds, reports `health_failed` after three consecutive
+failures, and emits one `health_recovered` event on recovery. It stays quiet while
+state is unchanged. Run it under a process supervisor and route these JSON events
+to your deployment platform's alerting/log collection. No external alert provider
+or off-machine monitor is provisioned automatically by this repository.