SKYHOUSE.dev Journal

Why: An audit of every Telegram message this box can send turned up eleven templates that came from raw curl calls rather than the shared sender — and eight of those belonged to scripts that had not run since June.

We went looking for message wording and found dead code instead. Six scripts from the Dynadot era were still sitting in ~/bin looking exactly like live tooling: executable, recently-edited-looking, named after things that still matter. None of them had been invoked since 2026-06-07, when DNS moved to Cloudflare and the flattened apex made the whole category of work unnecessary.

1. What moved, and how we knew it was safe

The evidence that they were dead was three-part, and worth writing down because "is this script live?" is a question that comes up constantly on this box:

• Not in any crontab. The plex crontab lists none of them. Root's crontab could not be read directly, but grepping /var/log/syslog for CRON[...] (root) CMD shows root's only custom entry is docker-log-guard.sh.
• Not sourced by anything live. A grep across ~/bin found no references from any scheduled script. The one shared dependency, lib-pubip.sh, stays — dns-monitor.sh needs it — and its header comment, which still named three retired callers, was corrected.
• Not logging. ~/.cache/ip-watch.log ends 2026-06-07, and its last line is a dry-run. ~/.cache/dns-watchdog.log ends the same day.

All six moved to /home/plex/bin/retired/ with a README.md that records what each did, what replaced it, and how to bring one back. Nothing was deleted: the point of keeping them is a Dynadot rollback, and that path is still intact.

2. Eight alert templates that could never fire

The reason this mattered beyond tidiness: these six carried eight Telegram message templates between them, each built on its own private tg() function. They predate telegram_notify.sh, so they had no hostname header, no HTML escaping, no truncation guard and no send log — and their text was worse than absent. The ip-recovery-verify.sh timeout message still walked you through re-pushing an A record to ns1.dyna-ns.net, a nameserver this domain has not used since June. An alert that fires once a year and then misdirects you is worse than no alert.

3. The documents that still described the old world

Retiring the scripts meant the docs pointing at them had to move too, or the next person to read them would go looking in ~/bin.

• cheatsheet.html — the Dynadot-era row now names all six and their new path; two stale references to ~/.cache/ip-watch.log (in the log table and in the post-disk-swap verification block) now point at ~/.cache/dns-monitor.log, which is the log that actually gets written.
• docs/server-context.md — the DNS architecture section now records the move and the reasoning.
• troubleshooting.html — two entries told you that ip-watch.sh would fix a stale A record. They now describe what actually happens, which is Cloudflare following the router's DDNS name on its own.
• docs/server-runbook.md and docs/ddns-playbook.md are wholesale Dynadot-era documents. Rewriting them was out of scope, so each got a banner at the top marking the DDNS sections superseded and naming the live replacement. The runbook's banner is explicitly scoped — the rest of that document is still correct.

Six scripts and eight dead alert templates out of the live tree, with the rollback path preserved and every living document that pointed at them corrected in the same change.