Why You Need Two Uptime Checks (Not One) and How to Set Them Up in 10 Minutes

Imagine finding out that 30% of your mobile customers have been unable to reach your website for the past two weeks. Your monitoring tool never fired a single alert. Your team had no idea. And the reason? Your site works perfectly over IPv4, but it has been completely broken over IPv6. One protocol up, the other down, and your single uptime check only tested the one that worked.

This is not a hypothetical scenario. It happens to businesses every day. The majority of uptime monitoring tools default to IPv4 when they run a check. They resolve your domain, pick the IPv4 address, confirm the site responds, and mark it as "up." Meanwhile, IPv6 users see timeout errors, broken pages, or nothing at all. Your dashboard shows 100% uptime. Reality tells a different story.

The fix is straightforward: create two separate monitors, one that forces IPv4 and one that forces IPv6. Each checks its own protocol independently. When one goes down while the other stays up, you get a clear, specific alert telling you exactly which protocol failed. This guide walks you through the entire process in plain English, no networking background required. If you can click a few buttons and copy-paste a command, you can do this.

Why a Single Monitor Is Not Enough

Before we get into the setup steps, it helps to understand why this matters to your bottom line. Your website has two "doors" that visitors can walk through: IPv4 and IPv6. Think of them as two separate entrances to your store. A standard uptime monitor only checks one entrance. If that entrance is open, it reports "store is open" and moves on. Nobody checks the other door.

The problem is that a growing share of internet traffic comes through the IPv6 door. Mobile carriers in India, Brazil, Japan, and the United States route significant traffic over IPv6. Apple requires IPv6 support for apps. Major cloud providers default to IPv6 for new deployments. If your IPv6 entrance is locked, barricaded, or simply missing, those visitors bounce. They do not send you a polite error report. They leave and go to a competitor.

The business cost is real. Every hour your IPv6 endpoint is down, you are losing a portion of your traffic without any indication in your metrics. Your analytics platform may not even distinguish between the two protocols, so the lost visitors simply vanish from your data. Separate monitors make this invisible problem visible. That is the entire value proposition: two monitors, two protocols, complete visibility. For a deeper look at the business impact, read about the hidden IPv6 downtime you might be missing.

Before You Start: A Quick DNS Sanity Check

Your website can only be reached over IPv6 if your domain name system (DNS) has the right records in place. DNS is the system that translates your domain name (like example.com) into an IP address that computers use to connect. There are two types of records that matter here:

• A record: This points your domain to an IPv4 address (looks like 192.0.2.45).
• AAAA record: This points your domain to an IPv6 address (looks like 2001:db8::45).

You need both. If you only have an A record and no AAAA record, there is nothing for IPv6 users to connect to. Setting up an IPv6 monitor would just tell you "it is down" every single time, which is accurate but not useful until you fix the DNS first.

How to check (ask your developer, or do it yourself)

If you have access to a terminal (Mac Terminal, Windows Command Prompt, or Linux), run these two commands with your real domain instead of "example.com":

# Check for an IPv4 address
dig A example.com +short
# You should see something like: 192.0.2.45

# Check for an IPv6 address
dig AAAA example.com +short
# You should see something like: 2001:db8::45

On Windows, the equivalent commands are:

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

If you are not comfortable running commands, no problem. Send your developer or hosting provider a one-line message: "Does our domain have both an A record and an AAAA record in DNS?" They will know instantly.

What your results mean

Optional: verify the addresses actually respond

If you want to go one step further, you can test whether each address actually returns a web page:

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

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

If the IPv4 test succeeds but the IPv6 test fails or times out, congratulations: you have just discovered exactly the kind of problem that separate monitors are designed to catch. That issue has likely been affecting real users already. For troubleshooting steps, see our guide on common IPv6 connectivity issues.

Step 1: Create Your IPv4 Monitor

Log in to your UptyBots dashboard. This is where you will create the first of your two monitors.

1. Click "New Monitor" in your dashboard.
2. Choose the monitor type. For most business websites, select HTTP. If you are monitoring an API endpoint, choose API. For raw network connectivity, choose Ping or Port. Not sure which one? HTTP is almost always the right choice for a website.
3. Enter your URL: Type your full website address, like https://example.com.
4. Set Network Type to IPv4. This is the key setting. It tells UptyBots to resolve your domain using only the A record and connect exclusively over IPv4. Without this setting, the monitor might pick either protocol and you lose the protocol-specific visibility.
5. Pick a check interval. How often should UptyBots test your site? For business-critical services, 1-minute intervals give you the fastest possible detection. For less critical pages, 5-minute intervals work well and keep your dashboard calmer.
6. Select monitoring regions. Choose locations where your customers are. If you serve customers in Europe and North America, pick regions in both areas. Multi-region checks catch problems that only affect certain geographies.
7. Click Save.

That is it for the IPv4 side. Your monitor is now active and will begin collecting data within the first check interval. You should see your first result appear on the dashboard within a minute or two.

Pick a clear naming convention

When you get an alert at 2 AM, you need to know instantly which protocol is affected. Use names that make the protocol obvious:

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

This seems small, but when you have 20 monitors running and an alert comes in, the difference between "example.com" and "example.com - HTTP IPv6" is the difference between confusion and immediate clarity.

Step 2: Create the Matching IPv6 Monitor

Now you create the second monitor. The goal is to make it identical to the first in every way except one: it forces IPv6 instead of IPv4.

Option A: Duplicate the IPv4 monitor (fastest method)

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

Duplication copies everything: the URL, check interval, regions, expected response codes, and alert channels. The only difference is the protocol. This is the recommended approach because it guarantees the two monitors are testing the same thing, just over different networks.

Option B: Create from scratch

1. Click "New Monitor".
2. Enter the same URL: https://example.com.
3. Set Network Type to IPv6.
4. Match every other setting to your IPv4 monitor: same check type, same interval, same regions, same alert channels.
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, the divergence shows up immediately on your dashboard and in your alerts.

Step 3: Set Up Alerts So You Actually Get Notified

Monitors without alerts are like smoke detectors without batteries. They can see the fire, but nobody gets warned. Each monitor in UptyBots has its own alert configuration, which means IPv4 and IPv6 trigger separate, independent notifications. This is exactly what you want: when IPv6 goes down but IPv4 stays up, the alert specifically names the IPv6 monitor. No guessing.

Choose your notification channels

UptyBots supports several ways to receive alerts. For dual-stack monitoring, configure the same channels on both monitors so your team hears about failures regardless of which protocol breaks:

• Email: The alert includes the monitor name (showing the protocol), the type of failure, and the HTTP response code or error message. Good for non-urgent reviews and creating a paper trail.
• Telegram: Instant notifications to a Telegram channel or group chat. Perfect for teams that need to react fast. The message includes the protocol and failure details.
• Webhooks: Send structured JSON payloads to your incident management system, Slack workspace, or custom automation. The payload contains the monitor ID, name, and failure details, so your systems can automatically distinguish between IPv4 and IPv6 incidents and route them accordingly.

You can configure notification channels under your account settings at any time, then assign them to monitors individually. For tips on keeping notification volume manageable as you add more monitors, read about alert fatigue and how to manage it.

Set a sensible failure threshold

A single failed check does not always mean a real outage. Network hiccups happen. A packet gets lost. A check times out because of a brief spike. You do not want your phone buzzing at 3 AM for a one-off blip.

UptyBots lets you set how many consecutive failures must happen before an alert fires. Here is a practical starting point:

• Business-critical production services: Alert after 2 consecutive failures. This filters out transient noise while still catching real outages within 2 to 3 minutes.
• Internal tools or staging environments: Alert after 3 to 5 consecutive failures. You still want to know, but a few minutes of delay is acceptable.
• Keep both monitors on the same threshold. If your IPv4 monitor alerts after 2 failures, your IPv6 monitor should too. This makes comparisons fair and consistent.

Step 4: Add Monitors for Other Check Types

HTTP monitoring covers your website, but your online infrastructure likely has more moving parts. For complete dual-stack coverage, consider adding protocol-specific monitors for other services:

Ping monitors

Ping tests whether your server is reachable at the network level. It is the most basic form of "is this machine alive?" check. Creating separate IPv4 and IPv6 ping monitors helps you catch firewall misconfigurations and routing problems that might not affect HTTP directly but indicate underlying infrastructure issues.

One important note: some servers intentionally block ping requests for security reasons. If your server blocks ICMP, ping monitors will always show "down" even when everything else works. Check with your hosting provider, or see our guide on common ICMP ping monitoring mistakes.

Port monitors

Port monitors check whether a specific service port is open and accepting connections. They are useful for anything that does not speak HTTP: mail servers, database connections (if publicly exposed), custom application protocols. Common ports to monitor:

• Port 443 (HTTPS) and Port 80 (HTTP)
• Port 25 or 587 (email/SMTP)
• Port 5432 or 3306 (database, if accessible from outside)

SSL monitors

SSL monitors check your certificate expiration date, chain validity, and handshake success. Here is why this matters for dual-stack: certificates can be configured differently on IPv4 and IPv6 sockets. It is entirely possible for your IPv4 endpoint to serve a valid, up-to-date certificate while your IPv6 endpoint serves an expired one or a certificate for the wrong domain. Separate SSL monitors for each protocol catch this mismatch.

Step 5: Organize Your Dashboard

Two monitors per domain, potentially across multiple check types, can make your dashboard grow fast. A little organization up front saves confusion later.

Stick to a naming pattern

Use the same format across every monitor so you can scan your dashboard quickly:

[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 together

Use UptyBots's project grouping feature to keep all monitors for the same service in one place. When you investigate an incident, having the IPv4 and IPv6 monitors side by side makes it immediately obvious whether the problem is protocol-specific or affects everything.

Step 6: Read Your Results and Know What They Mean

After a few days of data collection, you will start seeing patterns. Here is how to interpret the most common ones:

Compare uptime percentages

If your IPv4 monitor shows 99.99% uptime and your IPv6 monitor shows 99.5%, that 0.49% gap represents real downtime that was invisible before. For a site doing $100,000 per month in revenue, even 0.5% hidden downtime translates to meaningful lost business. The gap between the two percentages is the exact measure of what you were missing with a single monitor.

Look at response time differences

Some difference between IPv4 and IPv6 response times is normal because they take different network paths. But if IPv6 is consistently 100 to 200 milliseconds slower than IPv4, that is worth investigating. Common causes include suboptimal IPv6 routing, a CDN that serves IPv6 traffic from a more distant edge location, or a load balancer that handles IPv6 connections less efficiently.

Watch for regional patterns

Multi-location monitoring might reveal that IPv6 works from some regions but fails from others. This is a strong indicator of regional connectivity or routing problems that only affect certain ISPs or transit providers.

Understand correlated vs. isolated failures

When both your IPv4 and IPv6 monitors fail at the same time, the problem is not protocol-specific. It is a general server outage, a DNS failure, or something else affecting your entire infrastructure. But when only the IPv6 monitor fails while IPv4 stays green, you know the issue is isolated to your IPv6 setup: a firewall rule, a misconfigured listener, a stale DNS record, or a routing problem. That distinction is the entire reason you created two monitors instead of one.

What Teams Typically Discover After a Few Weeks

Once dual-stack monitoring has been running for a while, most businesses discover one of these patterns:

Your Dual-Stack Monitoring Checklist

Use this checklist to confirm everything is in place:

1. Your DNS has both an A record and an AAAA record pointing to publicly accessible addresses.
2. IPv4 HTTP monitor is created and actively collecting data.
3. IPv6 HTTP monitor is created with identical settings (same URL, interval, regions, alert channels).
4. Alert channels are configured on both monitors (email, Telegram, webhooks, or your preferred method).
5. Monitor names clearly state the protocol (e.g., "Site - HTTP IPv4" and "Site - HTTP IPv6").
6. Both monitors use the same check interval and consecutive-failure threshold.
7. If applicable: separate Ping and SSL monitors created for each protocol.
8. Dashboard organized with protocol-paired monitors grouped together.
9. Initial results reviewed: both monitors show the endpoint as reachable.

The 10-Minute Version

If you skimmed everything above and just want the quickest path to dual-stack monitoring, here it is:

1. Confirm your domain has both A and AAAA DNS records (ask your developer or hosting provider if unsure).
2. Log in to UptyBots and create an HTTP monitor for your domain with Network Type set to IPv4.
3. Duplicate that monitor and change the Network Type to IPv6.
4. Add alert channels to both monitors.
5. Wait for the first check results. If both show green, you are covered. If IPv6 shows red, you just found a problem that was silently affecting your users.

That is all it takes. Five steps, ten minutes, and you now have visibility into a category of outages that most businesses never detect. Any IPv6-specific failure will be caught immediately and reported through your configured alert channels, instead of surfacing days or weeks later through user complaints or mysterious traffic drops.

For a deeper understanding of the technical reasons behind separate monitoring, read why monitoring IPv4 and IPv6 separately matters.

See setup tutorials or get started with UptyBots monitoring today.