counterweight/personal_infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
personal_infra/archive/uptime_kuma
History
counterweight 79942525b1
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>
2026-09-11 22:43:15 +02:00
..
deploy_uptime_kuma_playbook.yml archive: record Uptime Kuma monitors and setup before decommissioning 2026-09-11 22:43:15 +02:00
monitors.json archive: record Uptime Kuma monitors and setup before decommissioning 2026-09-11 22:43:15 +02:00
MONITORS.md archive: record Uptime Kuma monitors and setup before decommissioning 2026-09-11 22:43:15 +02:00
README.md archive: record Uptime Kuma monitors and setup before decommissioning 2026-09-11 22:43:15 +02:00
setup_backup_uptime_kuma_to_lapy.yml archive: record Uptime Kuma monitors and setup before decommissioning 2026-09-11 22:43:15 +02:00
uptime_kuma_vars.yml archive: record Uptime Kuma monitors and setup before decommissioning 2026-09-11 22:43:15 +02:00

README.md

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.