« All posts

4 self-hosting failures that quietly report success

Four silent self-hosting failures — 200 OK pages, false healthchecks, empty backups, vanished WoL packets — and how to actually catch them.

The costliest failures in three years of self-hosting weren't the ones that threw errors — they were the ones reporting success while silently broken: a 200 OK page, a healthcheck marked healthy, a backup command that exits clean. Drawing from a single Docker/Caddy/Tailscale box, four concrete cases are dissected: an on-demand loading page (Sablier) that returns 200 with HTML instead of the XML a WebDAV client expects, breaking Obsidian sync while Nextcloud itself stays healthy; a Collabora healthcheck that silently rots after curl is stripped from the image, keeping a container falsely flagged unhealthy; MariaDB and SQLite backups that exit 0 but end up empty or truncated due to timing and permission issues; and a Wake-on-LAN packet aimed at a sleeping machine's Tailscale IP that vanishes because there's no OS or IP stack to receive it at layer 3.

The common thread is a system returning a success signal — status code, exit code, a green dashboard — without anything actually verified end to end. The practical takeaway for engineers is to stop asking 'what threw an error' and start asking 'what's reporting success that was never truly tested.' Concrete fixes are included: a dependency-free /dev/tcp healthcheck, polling MariaDB before dumping, backing up a root-owned SQLite file via a borrowed container, and relaying WoL packets over the local broadcast domain — all backed by a sanitized compose/Caddyfile repo.