Fixed the subdomain and monitoringmain

1 files changed, 6 insertions, 0 deletions

diff --git a/README.md b/README.md
index c0c887a..cba01b8 100644
--- a/README.md
+++ b/README.md
@@ -20,6 +20,12 @@ All secrets and per-deployment config (VPN credentials, Gandi DNS token, LAN/Tai
 
 All images (including Gluetun) track `:latest`. Nothing auto-updates — re-run `./deploy.sh` to pull and recreate everything. This is deliberate: `gluetun` and `qbittorrent` share a network namespace (`network_mode: "service:gluetun"`), so updates need to recreate both together, which a project-level `docker compose pull && up -d` does correctly and a per-container auto-updater would not.
 
+## Monitoring
+
+Every service has a real `HEALTHCHECK` (not just "is the process alive" — e.g. qbittorrent's also curls an external IP through gluetun's tunnel, since its WebUI keeps responding even when the VPN is dead). `autoheal` watches Docker's health status and runs `docker restart` on anything reporting `unhealthy`. `uptime-kuma` (at `status.karanj.com`) is the dashboard — monitors aren't config-as-code, so after a fresh deploy log in and add a "Docker Container" monitor per service plus an HTTP monitor per public hostname.
+
+**Caveat:** `qbittorrent` shares `gluetun`'s network namespace (`network_mode: "service:gluetun"`), and autoheal restarts containers individually — it has no notion of "restart this one's dependents too." Both carry equivalent connectivity healthchecks so they should flip `unhealthy` and get restarted within a cycle or two of each other, but it's not perfectly atomic. If qbittorrent ever looks stuck after a gluetun restart, `docker compose restart gluetun qbittorrent` (together) is the manual fallback — that's what actually fixed the Aug 2026 VPN outage.
+
 ## Gotchas
 
 - **Gluetun blocks inbound container-to-container traffic by default** — `FIREWALL_INPUT_PORTS=8123` in `docker-compose.yml` is required, or qBittorrent's WebUI (proxied by Caddy for `dl.karanj.com`) returns a 502.