Detect IPv6 Outages Hidden by Healthy IPv4 Checks

Define two independent checks

A dual-stack hostname can be reachable over IPv4 while its IPv6 firewall, route, listener, or load balancer is broken. A client that falls back successfully may show a green result while other users wait or fail. Create separate check identities such as portal-ipv4 and portal-ipv6 against the same hostname and application assertion.

First confirm the hostname is intended to publish both A and AAAA records. A service that deliberately offers only IPv4 has a different contract. Do not label missing IPv6 support an outage unless IPv6 is part of the service promise.

Force the family without changing the hostname

Run from a host with working connectivity for both families and permission to connect directly. These curl options (opens in a new tab) select each family while retaining the hostname for TLS and HTTP. Replace the example URL with your own controlled endpoint and record both command results independently.

The --noproxy '*' option excludes inherited proxy settings. Through an HTTP CONNECT proxy, -4 or -6 can select the family used to reach the proxy while the proxy independently chooses the origin connection. If a proxy is mandatory, use an approved probe location or verify its upstream family separately before claiming origin IPv4 or IPv6 coverage.

curl --noproxy '*' -4 --fail --silent --show-error --connect-timeout 5 --max-time 15 \
  https://portal.example.com/health
curl --noproxy '*' -6 --fail --silent --show-error --connect-timeout 5 --max-time 15 \
  https://portal.example.com/health

Check the expected response body as well as the exit status. These commands demonstrate transport selection; they do not by themselves validate your application's full health contract.

If using blackbox exporter, inspect preferred_ip_protocol and ip_protocol_fallback in the installed configuration reference (opens in a new tab). A preference with fallback enabled is not equivalent to a forced-family test. Keep separate modules or equivalent supported configurations for the two paths.

Locate the failing stage

An IPv6 failure from one network does not identify the failing operator automatically. Compare a second independent IPv6-capable location and collect the destination address and time window. Avoid changing firewall rules until you know which path was actually tested.

Represent partial availability honestly

Keep the family label through alert routing, dashboards, and history. Do not let the latest successful IPv4 sample resolve an IPv6 incident with the same generic key. If the service has one overall status, define how a family-specific failure is shown as degraded service and which responder owns it.

Run a controlled lab test that blocks the test endpoint's IPv6 listener while leaving IPv4 available. The IPv4 check should remain green, the IPv6 check should fail, and the combined view should retain the partial failure. Then break the probe host's IPv6 path instead and confirm it is identified as monitoring uncertainty when reference targets fail too.

Re-test after CDN, DNS, firewall, and hosting changes. An address-family check is only useful if it continues to traverse the family it claims to measure.