How to Set Up Separate IPv4 and IPv6 Uptime Checks (Step-by-Step Guide)

A single uptime monitor that checks your domain without specifying a protocol will almost always connect over IPv4. This means your IPv6 endpoint could be completely unreachable, and your monitoring dashboard would show 100% uptime. To catch protocol-specific failures, you need separate monitors -- one for IPv4, one for IPv6 -- each independently checking reachability, response time, and SSL validity.

This guide walks you through the complete process: verifying your DNS prerequisites, creating both monitors in UptyBots, configuring alerts, and organizing your dashboard for clear dual-stack visibility. By the end, you will have monitoring in place that catches the hidden IPv6 downtime that single-protocol checks miss.

Prerequisites: Verify Your DNS Is Dual-Stack Ready

Before creating monitors, you need to confirm that your domain actually resolves to both IPv4 and IPv6 addresses. This requires both an A record (IPv4) and an AAAA record (IPv6) in your DNS configuration.

Check your current DNS records

Run these commands to verify both record types exist:

# Check IPv4 address (A record)
dig A example.com +short
# Expected output: 192.0.2.45

# Check IPv6 address (AAAA record)
dig AAAA example.com +short
# Expected output: 2001:db8::45

On Windows, use nslookup:

nslookup -type=A example.com
nslookup -type=AAAA example.com

What the results mean

Quick connectivity test

Before setting up monitoring, verify that the addresses actually respond:

# Test IPv4 HTTP response
curl -4 -I https://example.com

# Test IPv6 HTTP response
curl -6 -I https://example.com

If the IPv4 test succeeds but the IPv6 test fails, you have an existing IPv6 issue that monitoring will detect and alert you about. That is exactly the kind of problem separate monitors are designed to catch. See our guide on common IPv6 connectivity issues for troubleshooting steps.

Step 1: Create an IPv4 HTTP Monitor

Log in to your UptyBots dashboard and create your first monitor:

1. Click "New Monitor" in your dashboard.
2. Select the monitor type. For most websites, choose HTTP. For APIs, choose HTTP or API. For raw connectivity testing, choose Ping or Port.
3. Enter your target URL or domain: https://example.com.
4. Under Network Type, select IPv4. This forces all checks to resolve and connect using the A record only.
5. Set your check interval. For production services, 1-minute intervals provide the fastest detection. For less critical services, 5-minute intervals reduce noise while still catching outages promptly.
6. Select your monitoring regions. Choose regions where your users are located. Multi-region monitoring catches issues that only affect specific geographic areas.
7. Click Save.

Your IPv4 monitor is now active. UptyBots will begin checking your endpoint over IPv4 immediately, and you should see your first results within the check interval.

Naming convention

Use a clear naming scheme that makes it obvious which protocol each monitor uses. Examples:

• example.com - HTTP IPv4
• example.com - HTTP IPv6
• api.example.com - API IPv4
• api.example.com - API IPv6

This naming convention makes it immediately clear in alert notifications and dashboards which protocol is affected.

Step 2: Create the IPv6 Monitor

Now create the matching IPv6 monitor. You have two options:

Option A: Duplicate the IPv4 monitor (fastest)

1. Open the IPv4 monitor you just created.
2. Click "Duplicate Monitor".
3. Change the Network Type from IPv4 to IPv6.
4. Update the monitor name to reflect IPv6 (e.g., change "HTTP IPv4" to "HTTP IPv6").
5. Click Save.

Duplication copies all settings (URL, check interval, regions, expected status codes, alert channels) so the two monitors are identical except for the protocol.

Option B: Create a new monitor manually

1. Click "New Monitor".
2. Enter the same URL: https://example.com.
3. Under Network Type, select IPv6.
4. Match all other settings to your IPv4 monitor: same check type, interval, regions, and alert configuration.
5. Click Save.

Both monitors are now running independently. UptyBots resolves the domain's A record for the IPv4 monitor and the AAAA record for the IPv6 monitor, then connects using the corresponding protocol. If one protocol fails while the other succeeds, you will see the divergence immediately.

Step 3: Configure Alerts for Protocol-Specific Notifications

Alerts are configured per monitor, which means each protocol triggers its own independent notifications. This is exactly what you want: when IPv6 goes down but IPv4 stays up, you get an alert specifically identifying the IPv6 failure.

Alert channels

UptyBots supports multiple notification channels. For dual-stack monitoring, configure the same channels for both monitors so your team is alerted regardless of which protocol fails:

• Email: Alert details include the monitor name (which shows the protocol), the failure type, and the response code or error message.
• Telegram: Instant notifications to your Telegram channel or group, with protocol and error details.
• Webhooks: Send structured JSON payloads to your incident management system (PagerDuty, Opsgenie, custom tools). The webhook payload includes the monitor ID and name, letting your automation distinguish between IPv4 and IPv6 failures.

Configure notification channels under your account settings before creating monitors, or add them to existing monitors at any time. For guidance on managing notification volume, read about alert fatigue and notification management.

Alert timing considerations

When a transient network issue causes a single failed check, you do not necessarily want an immediate alert. UptyBots allows you to configure how many consecutive failures trigger an alert. For dual-stack monitoring:

• Production services: Alert after 2 consecutive failures. This avoids false positives from transient blips while still detecting real outages within 2-3 minutes.
• Non-critical services: Alert after 3-5 consecutive failures for a calmer notification experience.
• Both protocols should use the same threshold so you can compare their behavior fairly.

Step 4: Set Up Additional Check Types

HTTP monitoring is the most common check type, but for comprehensive dual-stack coverage, consider adding protocol-specific monitors for other check types:

Ping monitors (ICMP)

Ping monitors test raw network reachability at the ICMP layer. They detect network-level failures (firewall blocking, routing issues) that may or may not affect HTTP. Create separate IPv4 and IPv6 ping monitors for your critical infrastructure.

Note that some servers block ICMP, which will cause ping monitors to show failures even when HTTP works fine. See ICMP ping monitoring mistakes for guidance on avoiding false positives.

Port monitors (TCP)

Port monitors check whether a specific TCP port is open and accepting connections. Useful for monitoring services that do not speak HTTP, such as database servers, mail servers, or custom TCP services. Create IPv4 and IPv6 port monitors for each critical port:

• Port 443 (HTTPS)
• Port 80 (HTTP)
• Port 25/587 (SMTP)
• Port 5432/3306 (database, if publicly exposed)

SSL monitors

SSL monitors validate certificate expiry, chain completeness, and handshake success. Because SSL certificates can be bound differently to IPv4 and IPv6 sockets, creating separate SSL monitors for each protocol catches cases where the IPv6 endpoint serves an expired or mismatched certificate while IPv4 is fine.

Step 5: Organize Your Dashboard

With separate monitors for each protocol and each check type, your dashboard can grow quickly. Keep it organized:

Use consistent naming

Adopt a naming pattern and use it consistently across all monitors:

[domain] - [check type] [protocol]

Examples:
  example.com - HTTP IPv4
  example.com - HTTP IPv6
  example.com - Ping IPv4
  example.com - Ping IPv6
  api.example.com - API IPv4
  api.example.com - API IPv6

Group related monitors

Use UptyBots's project grouping to keep IPv4 and IPv6 monitors for the same service together. This lets you see both protocols side by side when investigating an incident.

Step 6: Read and Compare the Results

Once both monitors have collected data, compare their metrics. Here is what to look for:

Uptime percentage

If your IPv4 monitor shows 99.99% uptime but your IPv6 monitor shows 99.5%, you have recurring IPv6 issues that need investigation. The gap between the two percentages quantifies the hidden downtime you were previously missing.

Response time differences

It is normal for IPv4 and IPv6 response times to differ slightly, because they use different network paths. However, consistently higher IPv6 latency (e.g., 200 ms vs 50 ms) suggests suboptimal IPv6 routing or a CDN that serves IPv6 traffic from a more distant edge node.

Regional patterns

Multi-location monitoring may reveal that IPv6 works well from some regions but fails from others. This indicates regional connectivity or routing issues that need attention.

Correlated failures

If both IPv4 and IPv6 monitors fail simultaneously, the issue is not protocol-specific -- it is a general server or DNS outage. If only IPv6 fails while IPv4 remains up, the issue is specific to IPv6 infrastructure (firewall, listener, DNS, routing). This distinction is the entire reason for separate monitors.

Common Patterns You Will Discover

After running dual-stack monitoring for a few days or weeks, teams typically discover one of these patterns:

Checklist: Complete Dual-Stack Monitoring Setup

Use this checklist to verify you have complete dual-stack monitoring coverage:

1. DNS has both A and AAAA records pointing to publicly routable addresses.
2. IPv4 HTTP monitor created and active.
3. IPv6 HTTP monitor created and active with matching settings.
4. Alert channels configured on both monitors (email, Telegram, webhook).
5. Monitor names clearly identify the protocol (e.g., "Site - HTTP IPv4", "Site - HTTP IPv6").
6. Both monitors use the same check interval and consecutive-failure threshold.
7. If applicable: separate ping and SSL monitors for each protocol.
8. Dashboard organized with protocol-paired monitors grouped together.
9. Initial results reviewed: both monitors show the endpoint as reachable.

Once this setup is in place, you have true dual-stack visibility. Any IPv6-specific failure will be detected immediately and reported through your configured alert channels, rather than surfacing hours later through user complaints. For a deeper understanding of why this separation matters, read why monitoring IPv4 and IPv6 separately matters.

See setup tutorials or get started with UptyBots monitoring today.