fix(netbird-proxy): watchdog restart cooldown 600 s -> 60 s

Every loss of the routing peer a proxy has pinned wedges its route manager; the flood watchdog restarts the container within 2 s and the public edge is back after one failed probe round. Inside the 600 s cooldown the restart is suppressed and the URL watchdog three one-minute rounds are the only recovery: 3.5 min of 000 on every public domain, measured 2026-09-07 10:28 on proxy-2 ("restart suppressed, last restart 567s ago"). The morning node roll hit the same suppression on both proxies at 06:58 and survived only because the routes recovered by luck. Rolling reboots lose one peer every few minutes by design, so with 600 s the second roll is always the unlucky one. A minute keeps the loop protection (one restart per probe interval at most). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-07 10:38:28 +02:00
1 changed files with 7 additions and 2 deletions
@@ -32,8 +32,13 @@ netbird_watchdog_fail_threshold: 3

 # Minimum seconds between watchdog-issued restarts, so a genuinely broken
 # backend can't put the proxy into a restart loop. Shared by both the URL-probe
-# watchdog and the flood watchdog below.
-netbird_watchdog_cooldown_seconds: 600
+# watchdog and the flood watchdog below. One minute: the route-manager wedge
+# recurs on every routing-peer loss, and rolling node reboots lose one peer
+# every few minutes; a suppressed restart there leaves the wedge standing
+# until the URL probe's three rounds fire (3.5 min of 000 on every domain,
+# measured 2026-09-07). A minute still caps a loop at one restart per
+# probe interval.
+netbird_watchdog_cooldown_seconds: 60

 # Log fingerprint of the reverse-proxy route-manager wedge, matched as a plain
 # substring in the proxy's docker logs by the flood watchdog. On this build the