Service Containers

One dashboard for every Adom service container: what is healthy, what is down, why, and a restart button that runs the watchdog's own start command.

It does not probe anything

service-watchdog.sh already checks every container every 5 minutes and writes one verdict per check into ~/.watchdog-state. svcwatch reads those files. It never re-probes.

That is not laziness, it is the point. Mouser's ?live=true burns a search slot exactly like a real query, so a dashboard that probed on every page load would spend the quota the service exists to spend on real work. Reading the verdict costs nothing, so the page can refresh every 15 seconds.

It also means staleness is a real signal. If the newest verdict is more than 15 minutes old, the page says the watchdog itself has stopped. That is the failure mode that once hid a 7.3 hour OAuth Gateway outage: one stalled SSH held the watchdog's lock, every later cron cycle exited silently, and nothing anywhere said so.

What a card tells you

Each service shows every check the watchdog runs for it, and each check says what it means rather than what it measures. "Auto-deploy from main still works" beats "git-auth ok". A failing check replaces its description with the watchdog's actual reason.

Restart runs the exact start_cmd from that service's row in service-watchdog.sh, so the button can never drift from what the watchdog would do unattended. A service with no start command in TARGETS gets a disabled button and a tooltip saying to add one, rather than a button that would fail.

On a phone

One 44px header row at every width. As space runs out the header sheds the meta line, then the subtitle, then the subject name. The status LED and the healthy count go last, because they are why you opened it.

Settings

Refresh rate, idle shutdown, and which sections show. Every row states its default.

Commands

svcwatch serve [--print-url]   start the server (self-backgrounds, prints the URL)
svcwatch show                  open or refresh the Service Containers tab
svcwatch status                one-line health of every service container
svcwatch health                is svcwatch itself up
svcwatch ls                    running instances, with version drift
svcwatch stop                  shut every instance down
svcwatch ui toast "..."        raise a toast on the page
svcwatch ui sweep              run a watchdog sweep now
svcwatch ui restart <svc> --reason "..."

ui restart refuses without a written --reason. Restarting a shared service interrupts whoever is using it, so the reason is recorded, not decorative.

Adding a service

svcwatch keeps no service list. It reads the TARGETS rows in ~/bin/service-watchdog.sh, so adding a row there makes the card appear with its host, port, SSH target and start command already filled in.