archive: record Uptime Kuma monitors and setup before decommissioning

Captured from the live instance rather than the repo: the playbooks created 17
monitors, the server had 75. The rest existed only in the UI. Push tokens are
excluded deliberately — they are live credentials.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

archive/uptime_kuma/README.md

@@ -0,0 +1,51 @@
+# Uptime Kuma — archived
+
+Uptime Kuma was the monitoring stack for this infrastructure until **2026-09-11**, when
+it was decommissioned. Everything that referenced it has been removed from the live
+playbooks; this folder is the record of what it was, kept so the setup can be understood
+later without digging through git history.
+
+## Contents
+
+| File | What it is |
+|---|---|
+| `MONITORS.md` | Every monitor that existed, grouped as it was in the UI. The authoritative record. |
+| `monitors.json` | The same data, machine-readable, as returned by the API. |
+| `deploy_uptime_kuma_playbook.yml` | How the server itself was deployed (Docker Compose on `monitoring`, behind Caddy). |
+| `uptime_kuma_vars.yml` | Variables the deploy playbook needed — it is unreadable without these. |
+| `setup_backup_uptime_kuma_to_lapy.yml` | How its data was backed up, and to where. Useful when disposing of the old volumes. |
+
+## Why the inventory was captured from the live server, not the repo
+
+The playbooks only ever created **17** monitors. The live instance had **75**. The
+difference was created by hand in the UI and existed nowhere else — so a repo-derived
+list would have silently lost two thirds of the picture. `MONITORS.md` is a snapshot of
+the real thing, taken immediately before removal.
+
+Push tokens are deliberately excluded. They are live credentials — anything holding one
+can report a false "up" — and they become meaningless once the server is gone.
+
+## What removal did NOT do
+
+Removing the playbook code does not touch the machines. **48 push monitors** were driven
+by scripts and systemd timers installed *on the hosts*, which keep firing on their
+schedule and curling an endpoint that no longer answers. They are harmless but they are
+still there, writing logs and failing quietly.
+
+Left behind, per host:
+
+- `/opt/disk-monitoring` + `disk-usage-monitor.{service,timer}` — on all 12 `managed` hosts
+- `/opt/system-healthcheck` + `system-healthcheck.{service,timer}` — on all 12 `managed` hosts
+- `/opt/nodito-monitoring` + `nodito-cpu-temp-monitor.{service,timer}` — `nodito`
+- `/opt/zfs-monitoring` — `nodito`
+- `/opt/ups-monitoring` — `nodito`
+- `bitcoin-knots-healthcheck.{service,timer}` — `bitcoin`
+- `datum-gateway-healthcheck.{service,timer}` — `bitcoin`
+- `fulcrum-healthcheck.{service,timer}` — `electrum`
+- `mempool-{backend,frontend,mariadb}-healthcheck.service` — `mempool`
+- phoenixd and forgejo-runner healthcheck units — `edge`, `ci_runner`
+
+Note `nut-monitor.service` on `nodito` is **NUT's own daemon**, not a monitoring
+leftover — do not remove it with the rest.
+
+Cleaning these up is a separate decommissioning pass and was not part of the removal.