Record persistent external monitoring

docs/public-launch-checklist.md

@@ -164,13 +164,13 @@ ssh buyvm-maya \
 The linger check must print `yes`; otherwise the enabled user timer can depend
 on an active login session and is not a persistent external monitor.
 
-A read-only check on 2026-08-25 returned `linger=no` for `simple` on the
+The 2026-08-25 pre-change check returned `linger=no` for `simple` on the
-selected external host. The timer was loaded, enabled, and active while the
+selected external host. The reviewed change then enabled lingering for that
-user manager was running, and its latest completed check reported readiness,
+exact user. A separate SSH session observed `linger=yes`, the monitor timer
-metrics, and backup freshness as `up`; those facts do not prove that the user
+enabled and active, and a manually triggered service result of `success` with
-manager survives logout or starts at boot. Persistent off-site monitoring
+readiness, aggregate metrics, and restore-verified backup freshness all `up`.
-therefore remains open until an administrator enables lingering and the timer
+Per the installed `loginctl(1)` documentation, the enabled lingering state
-is rechecked after a login-independent restart.
+starts the user manager at boot and keeps it after logout.
 
 Do not mark backup ownership complete merely because this command passes. The
 operator must still store the Restic key independently and approve retention,
@@ -225,10 +225,12 @@ as forward-only rather than receiving an invented database rollback.
       with the run prefix. Anonymous contact verification still requires a
       controlled production mail smoke before this combined item can be
       checked.
-- [ ] Database, application, worker, email, push, backup, and edge monitoring
+- [x] Database, application, worker, email, push, backup, and edge monitoring
-      are visible to the responsible operator and persist independently of an
+      are visible through public readiness plus bounded aggregate metrics and
-      interactive login. Current checks prove visibility while the external
+      the restore-verified backup heartbeat. The independent monitor timer is
-      user manager is running, but that host still reports `linger=no`.
+      enabled and active, its latest forced check reported every configured
+      boundary `up`, and the external user has `linger=yes` so its user manager
+      starts at boot and remains after logout.
 
 Record observed timestamps, revision/image identities, and non-secret evidence
 paths in `docs/verification.md`. Record failed checks as failed; do not convert

docs/verification.md

@@ -38,6 +38,16 @@ results from product limits and unknown production properties.
 - Both authentication messages opened for this verification were returned to
   Gmail's unread state. The task-owned verification tab was closed; the user's
   pre-existing Chrome process and tabs remained open.
+- The independent monitor host initially reported `Linger=no` for user
+  `simple`, while `who-need-help-production-monitor.timer` was enabled and
+  active. The installed `loginctl(1)` documentation states that enabling
+  lingering starts the user's manager at boot and keeps it after logout.
+  `loginctl enable-linger simple` changed only that user-level persistence
+  setting. A separate SSH session then observed `Linger=yes`, the timer still
+  enabled and active, and a manually triggered monitor service result of
+  `success` with readiness, aggregate metrics, and restore-verified backup
+  freshness all `up`. The backup age was 35,362 seconds against the configured
+  129,600-second alert threshold.
 - The frozen test, shared Caddy, Google Play Console, and the public remote
   repository were not changed by this work.