diff --git a/migration/vrrp-wan-health b/migration/vrrp-wan-health
new file mode 100755
index 0000000..736aa2b
--- /dev/null
+++ b/migration/vrrp-wan-health
@@ -0,0 +1,24 @@
+#!/bin/sh
+# VRRP health check: may THIS router hold the floating IPs?
+#
+# It may only if it can actually carry the WAN. Without this, VRRP decides
+# mastership purely on whether the peer is still advertising -- so a router with
+# no WAN at all happily takes the VIPs and blackholes the entire LAN's internet
+# while looking perfectly healthy. That is not hypothetical: it is the outage of
+# 2026-09-02, reproduced in labsim.
+#
+# The test is "do I have an ADDRESS on a WAN interface", deliberately NOT "can I
+# reach the internet" and NOT "do I have a default route". During a real ISP
+# outage the default route disappears on BOTH routers; a check keyed on that
+# would put both into FAULT, nobody would hold the VIPs, and the LAN would lose
+# inter-VLAN routing too -- turning an internet outage into a total one. An
+# address on a WAN interface distinguishes "this box structurally cannot route"
+# (the failure we must prevent) from "the internet happens to be down right now"
+# (which the router can do nothing about, and during which it should keep
+# serving the LAN).
+#
+# exit 0 = eligible for MASTER, non-zero = release and let the peer have it.
+for ifc in bond0.53 pppoe0; do
+    ip -4 addr show dev "$ifc" 2>/dev/null | grep -q 'inet ' && exit 0
+done
+exit 1