# uptime-kuma — the fleet's SERVICE-layer monitor. # # REBUILT FROM SCRATCH 2026-09-21 (operator-authorised: "uptime-kuma was never # really used... you can even dump the existing container and config and start # over from scratch"). The previous instance carried four monitors, all of them # firewall pings, and 21-month-old code. Nothing was migrated. # # ⚠️ IMAGE TAG — DO NOT USE `:latest` HERE. Upstream keeps `latest` pointing at # the 1.x line, so a pull in August 2026 handed us an image BUILT 2024-12-20 # (1.23.16). Measured, not assumed: `latest` and `1` resolve to the same # digest, while `2`/`next` carry 2.5.5. All development is on 2.x, which has # been stable since 2.2.0 (2026-03-05) across twelve releases with zero # prereleases. Pinned EXACTLY rather than floating on `2` for the same reason # `latest` burned us: a floating tag is a version you did not choose. # # MOVED esh-docker-vm -> ana-docker in the same rebuild, for two reasons: # 1. House placement rule (CLAUDE.md): "Cross-site services (e.g. Beszel hub, # Dozzle hub) live on ana-docker and pull from agents on the other hosts." # A fleet-wide service monitor is exactly that, and it now sits beside the # Beszel hub it complements. # 2. esh-docker-vm has wedged unkillably TWICE in four months (2026-06-03 and # 2026-09-18, both homepage in D-state). The fleet's service monitor should # not live on the least reliable box in the fleet — and a monitor cannot # report the failure of the host it runs on. Beszel covers the host layer; # this covers the service layer; they should not share a failure domain. # # THE LANE SPLIT this service exists to fill (measured 2026-09-21): # Beszel -> 18 hosts x {Status, CPU, Memory, Disk, Temperature}. Its alerts # bind to a SYSTEM with a threshold; there is no URL column, so it # is structurally incapable of "this endpoint should return 200". # Kuma -> is the service actually serving. This file. # Homepage-> DISPLAY ONLY. It polls 38 URLs and alerts nobody; it is a # dashboard, never a monitor. # The gap between the first two is where homepage sat dead for three days while # both tools reported correctly. name: uptimekuma services: uptime-kuma: image: louislam/uptime-kuma:2.5.5 container_name: uptime-kuma # Normalised from the adopted-as-run `always` — the 2026-08-18 README said # this was "worth normalising on the next deliberate touch", and a rebuild # from scratch is that touch. `always` revives a container that was stopped # ON PURPOSE, which is the wrong behaviour for a service we may deliberately # take down during maintenance. restart: unless-stopped environment: # Skips 2.x's interactive "choose a database" first-run screen. # setup-database.js: UPTIME_KUMA_DB_TYPE overrides db-config.json and # writes it, so the stack comes up ready for the admin-account step # instead of parking on a form. SQLite is right here -- one operator, # a few dozen monitors; MariaDB is for the multi-thousand-check case. UPTIME_KUMA_DB_TYPE: sqlite ports: - "3001:3001" volumes: - uptime-kuma:/app/data labels: # Monitoring, NOT Apps — this is the group the dashboard's layout reserves # for Backrest / Beszel / Dozzle / this. - homepage.group=Monitoring - homepage.name=Uptime Kuma - homepage.icon=mdi-arrow-up-bold-circle - homepage.description=Service monitoring (fleet) - homepage.href=http://10.250.50.70:3001 - homepage.siteMonitor=http://10.250.50.70:3001 # ⚠️ NO `homepage.widget.*` LABELS YET, deliberately. The widget needs a # published status-page slug; on a from-scratch install none exists, so # the widget would poll a 404 forever. That matters more than usual # here: homepage widgets pointed at dead targets are the suspected # mechanism behind BOTH of this dashboard's unkillable D-state wedges # (see incident_esh_docker_nfs_boot_race, 2026-06-03). Re-add the widget # labels only once the status page actually exists. networks: - tnet volumes: uptime-kuma: {} networks: tnet: name: traefik-net external: true