diff --git a/docs/public-launch-checklist.md b/docs/public-launch-checklist.md
index 04189c4..6c5bd16 100644
--- a/docs/public-launch-checklist.md
+++ b/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
-selected external host. The timer was loaded, enabled, and active while the
-user manager was running, and its latest completed check reported readiness,
-metrics, and backup freshness as `up`; those facts do not prove that the user
-manager survives logout or starts at boot. Persistent off-site monitoring
-therefore remains open until an administrator enables lingering and the timer
-is rechecked after a login-independent restart.
+The 2026-08-25 pre-change check returned `linger=no` for `simple` on the
+selected external host. The reviewed change then enabled lingering for that
+exact user. A separate SSH session observed `linger=yes`, the monitor timer
+enabled and active, and a manually triggered service result of `success` with
+readiness, aggregate metrics, and restore-verified backup freshness all `up`.
+Per the installed `loginctl(1)` documentation, the enabled lingering state
+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
-      are visible to the responsible operator and persist independently of an
-      interactive login. Current checks prove visibility while the external
-      user manager is running, but that host still reports `linger=no`.
+- [x] Database, application, worker, email, push, backup, and edge monitoring
+      are visible through public readiness plus bounded aggregate metrics and
+      the restore-verified backup heartbeat. The independent monitor timer is
+      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
diff --git a/docs/verification.md b/docs/verification.md
index 055bc63..8c3ef14 100644
--- a/docs/verification.md
+++ b/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.