IPv6 monitoring
PathWatch supports per-monitor IPv4 / IPv6 selection on the four
network-layer check types: HTTP, SSL, TCP port, and
Ping. Each selected family runs as a separate sub-check; the
monitor’s overall status is down if any selected family fails.
Where IPv6 runs today
Self-hosted runners only. Cloud runners are IPv4-only for the foreseeable future — the cost of routing IPv6 egress out of the managed cloud network outweighs the benefit for our pricing tier. The WebUI shows this state inline: a Self-hosted badge next to the IPv6 toggle and a “coming soon to cloud” tooltip.
What happens if you select IPv6 anyway
When the dispatcher assigns a cloud region to a monitor that also requests IPv6:
- The cloud sub-check strips IPv6 from the request. The cloud region runs only the IPv4 sub-check.
- A single
skippedresult is recorded for the IPv6 sub-check — this is excluded from success-criteria aggregation, so it doesn’t penalise your monitor. - If you requested IPv6-only (no IPv4 selected) on a cloud
region, the cloud sub-check is fully skipped and a single
skippedresult is recorded for the region. Pair the monitor with a self-hosted runner to actually exercise the IPv6 path.
How to enable IPv6 on a monitor
- Open the monitor’s edit page.
- In the IP versions picker, click the IPv6 chip. Both IPv4 and IPv6 are enabled by default on supported monitor types — leaving both selected is the recommended config.
- Assign at least one self-hosted runner to the monitor’s region
list. Without one, the IPv6 sub-check has no IPv6-capable
runner to dispatch to and will record
skippedeverywhere.
Self-hosted runner setup
Self-hosted runners use the host’s network stack for outbound connections. On any host with dual-stack networking enabled (most modern Linux servers, Hetzner / DigitalOcean / Vultr VMs, on-prem machines with IPv6 from the ISP) the runner picks up IPv6 automatically.
To verify your runner has IPv6:
docker exec -it pathwatch-runner curl -6 -sI https://example.comIf that returns a 200 OK, the runner can reach IPv6 targets.
If your hosting environment doesn’t provide IPv6 by default, see the self-hosted runner deployment guide on TechDocs for enabling dual-stack networking in Docker.
Per-check-type behaviour
| Monitor type | IPv6 toggle | Behaviour |
|---|---|---|
| HTTP / HTTPS | Yes | Runs an IPv4 and / or IPv6 sub-check. Aggregate is down if either fails. |
| SSL certificate | Yes | TLS handshake over each selected family. Failures on either go to down. |
| TCP port | Yes | Per-family TCP connect. Different status returned per family. |
| Ping | Yes | ICMPv4 / ICMPv6 echo. ICMPv4 runs from both cloud and self-hosted runners; ICMPv6 is self-hosted only (cloud checkers are IPv4-only). |
| DNS | No (resolver-driven) | The runner’s resolver chooses transport based on what’s configured. |
| Domain expiration / Keyword / Heartbeat / Browser | No | Either not network-layer (heartbeat is inbound) or browser-driven. |
Tips
- For public targets, leave both IPv4 and IPv6 enabled — modern
CDNs typically serve both, and the cost on a monitor with cloud
- self-hosted runners is essentially zero.
- For internal targets only reachable via IPv6 (some private Kubernetes meshes, AWS dual-stack VPCs), require a self-hosted runner explicitly in the runner picker — don’t rely on cloud regions for that monitor.
- If you see a wave of
skippedresults on IPv6 sub-checks, that’s the dispatcher filtering them out at cloud regions, not a real failure.