By David Kim · Feb 28, 2026

Uptime Monitoring FAQ: 10 Questions Answered at the Protocol Level

How exactly does a monitoring service decide your site is "down"? The answer is more nuanced than most documentation suggests, because it depends on which network protocol the check operates at, what the expected response looks like, and how the monitoring system interprets timeouts, resets, and partial responses at the transport and application layers.

This FAQ goes beyond surface-level definitions. Each answer explains the protocol-level mechanics behind uptime monitoring concepts, so you understand not just what these terms mean but how they actually work on the wire. Whether you are setting up your first monitor or debugging why a check reports downtime that users do not seem to experience, the protocol details here will fill in the gaps.

1. How Is Uptime Actually Measured at the TCP Level?

When a monitoring service checks whether your server is "up," the measurement starts with a TCP connection attempt. The monitor sends a SYN packet to your server's IP address and port. What happens next determines the result:

SYN-ACK received: The server's TCP stack responded. The three-way handshake completes (SYN, SYN-ACK, ACK). At the TCP level, the service is up. For a TCP port check, this is sufficient to report the target as healthy.
RST received: The server actively rejected the connection. This means the host is reachable, but nothing is listening on that port. This is reported as down.
No response (timeout): No SYN-ACK and no RST arrived before the timeout expired. This can mean the server is offline, a firewall is silently dropping the SYN packet (as opposed to rejecting it with RST), or network congestion delayed the response beyond the threshold. Reported as down.
ICMP Destination Unreachable: A router along the path returned an ICMP error (host unreachable, network unreachable, or administratively prohibited). This means the packet could not reach the destination. Reported as down.

The timeout threshold is a critical parameter. A server that responds in 12 seconds is technically reachable, but if the monitoring system's timeout is set to 10 seconds, the check reports a failure. Timeout values typically range from 5 to 30 seconds, and different services use different defaults. When comparing uptime numbers between monitoring providers, verify they use the same timeout.

For HTTP checks, the TCP handshake is just the first step. After the connection is established, the monitor sends an HTTP request and evaluates the full response. A server that accepts TCP connections but returns HTTP 503 (Service Unavailable) passes a TCP check but fails an HTTP check. This is why the type of check you configure directly affects the uptime percentage you see in reports.

2. What Is the Difference Between a TCP Check and an HTTP Check?

A TCP check and an HTTP check operate at different layers of the network stack, and each detects a different category of failure.

A TCP check operates at OSI Layer 4 (transport). It opens a connection to a port and verifies the handshake. The check has no knowledge of what protocol the application speaks. It simply confirms that a process is accepting connections. TCP checks are fast (typically 1-5 ms for a local check), lightweight (three packets), and protocol-agnostic. They work for any TCP service: PostgreSQL on 5432, SMTP on 25, SSH on 22, Redis on 6379, or a custom protocol on any port.

An HTTP check operates at OSI Layer 7 (application). After the TCP handshake, it sends an HTTP request and evaluates the response. This means the check validates the entire path: DNS resolution (Layer 7, if a hostname is used), TCP connection (Layer 4), TLS handshake (Layer 6, for HTTPS), and the HTTP request-response cycle (Layer 7).

What an HTTP check can validate that a TCP check cannot:

Status codes: A 200 OK means the application processed the request. A 500 Internal Server Error means the server is running but the application failed. A TCP check cannot distinguish these.
Response body: You can require that the response contains a specific string (e.g., "OK" or a JSON key). This catches cases where the server returns 200 but the body is an error page or empty.
Response time: The total time from sending the request to receiving the complete response. This measures application latency, not just network latency.
TLS validity: Whether the certificate is trusted, matches the hostname, and is not expired. A TCP check to port 443 does not perform TLS negotiation.
Redirect behavior: Whether the server redirects (301, 302) and where it redirects to. An unexpected redirect to a maintenance page is something an HTTP check can flag.

Use TCP checks for non-HTTP services. Use HTTP checks for anything that serves web traffic. For services that support both (like an API with a health endpoint), always prefer the HTTP check because it catches more failure modes.

3. How Does Ping Monitoring Work at the ICMP Level?

Ping uses ICMP (Internet Control Message Protocol), specifically ICMP Echo Request (type 8) and ICMP Echo Reply (type 0). When you run ping example.com, your system sends an ICMP Echo Request packet to the target. If the target is reachable and its OS is configured to respond, it sends back an ICMP Echo Reply. The round-trip time (RTT) between sending the request and receiving the reply is the ping latency.

At the protocol level, ICMP is a Layer 3 protocol that rides directly on IP (protocol number 1 in the IP header). It does not use TCP or UDP ports. This means ICMP ping tests reachability at the network layer but tells you nothing about whether any application-layer service is running. A server can respond to ping while every application on it is crashed.

Important ICMP behaviors to understand:

Firewall filtering: Many servers and networks block ICMP. If your target drops ICMP Echo Requests, ping shows 100% packet loss even though the server is perfectly healthy and serving HTTP traffic. This is a false negative. Before configuring a ping monitor, verify that the target actually responds to ICMP.
ICMP rate limiting: Some hosts rate-limit ICMP responses. If the monitoring service sends pings too frequently, some responses may be dropped by the rate limiter, causing intermittent false failures.
ICMP vs TCP latency: ICMP packets are often handled by the kernel's network stack before user-space processing. TCP packets go through more processing layers. This means ping latency is typically lower than HTTP response time, and comparing the two is not meaningful without understanding this difference.
IPv4 vs IPv6: ICMP for IPv4 (ICMPv4) and ICMP for IPv6 (ICMPv6) are separate protocols with different type/code values. ICMPv6 is also used for critical functions like Neighbor Discovery and Path MTU Discovery, so blocking ICMPv6 can break IPv6 connectivity entirely.

Ping monitoring is best used as a lightweight reachability check alongside more specific TCP or HTTP checks. It answers "is this host alive on the network?" but not "is this service working?"

4. Why Do Multi-Location Checks Give Different Results?

The internet is not a single network. It is a collection of thousands of autonomous systems (ASes) connected by peering and transit agreements. The path a packet takes from monitoring node A in Frankfurt to your server in Virginia is completely different from the path taken by monitoring node B in Tokyo. Different paths mean different potential points of failure.

Reasons multi-location checks produce different results:

BGP routing differences: Each monitoring location reaches your server through a different chain of autonomous systems. A peering dispute between two networks in Europe might cause Frankfurt to see your server as unreachable while Tokyo routes around the affected path without issue.
CDN edge failures: If you use a CDN, each monitoring location hits a different edge node. An edge node crash in one region causes failures from that location while others hit healthy edges.
DNS resolver behavior: Different locations may query different DNS resolvers that have cached different versions of your records. During a DNS migration, one resolver might still serve the old IP while another has the new one.
Submarine cable issues: Intercontinental traffic depends on submarine fiber cables. Damage to a cable can reroute traffic through longer paths, increasing latency or causing intermittent timeouts from specific regions.
Regional filtering: Some countries filter or throttle traffic to certain destinations. A monitoring node in such a country may see intermittent failures that other locations do not experience.
Asymmetric routing: The path from the monitor to your server (ingress) may differ from the return path (egress). A failure on the return path causes the check to fail even though your server processed the request successfully.

This is exactly why single-location monitoring can be misleading. A check from one location may show 100% uptime while users in another region experience daily outages. UptyBots offers multi-location monitoring on paid plans, so you get visibility into how your service performs from different parts of the internet.

5. What Defines a "False Positive" in Network Terms?

A false positive occurs when the monitoring system reports a failure that did not actually affect users. At the network level, false positives have specific causes:

Transient packet loss: A single SYN packet is lost due to congestion or a brief routing flap. The monitoring system's TCP timeout expires and the check fails. But a real browser would retry the SYN automatically (the kernel sends SYN retries at 1s, 3s, 7s intervals by default on Linux), and the second attempt succeeds. The user never noticed anything.
Monitoring node network issue: The monitoring node itself has a brief network interruption. From the monitor's perspective, the target is unreachable. From every other vantage point, the target is fine.
Asymmetric path failure: The SYN reaches the target, the target sends a SYN-ACK, but the SYN-ACK is lost on the return path. The monitor times out despite the server being fully operational.
TCP RST from middlebox: A firewall, NAT device, or intrusion prevention system between the monitor and the target sends a TCP RST in response to the SYN. The monitor reports the port as closed, but actual user traffic (perhaps from a different source IP or with different packet characteristics) passes through fine.
DNS timeout: The monitor's DNS resolution fails for a transient reason (recursive resolver overloaded, cache miss combined with a slow authoritative response). The check fails at the DNS stage, but users whose resolvers have the record cached are unaffected.

Multi-check confirmation reduces false positives. Requiring two or three consecutive failed checks before alerting filters out transient issues. Multi-location confirmation is even stronger: if a check fails from one location but passes from two others, it is almost certainly a path-specific issue rather than a real outage.

6. How Does SSL/TLS Monitoring Work at the Protocol Level?

SSL/TLS monitoring connects to a server on port 443 (or another TLS-enabled port), performs a TLS handshake, and validates the certificate chain. Here is what happens step by step:

TCP handshake: Standard SYN, SYN-ACK, ACK to establish the connection.
ClientHello: The monitor sends a TLS ClientHello message, specifying supported TLS versions, cipher suites, and the SNI (Server Name Indication) extension with the target hostname.
ServerHello + Certificate: The server selects a TLS version and cipher suite, then sends its certificate chain.
Certificate validation: The monitor verifies: (a) the certificate's Common Name or Subject Alternative Name (SAN) matches the hostname, (b) the certificate has not expired, (c) the certificate chain links to a trusted root CA, (d) the certificate has not been revoked (via CRL or OCSP), and (e) the chain is complete (no missing intermediate certificates).
Expiration tracking: The monitor reads the certificate's "Not After" date and calculates days until expiration. Alerts fire at configured thresholds (30 days, 14 days, 7 days, 1 day).

Common SSL issues that monitoring catches:

Missing intermediate certificate: The server presents the leaf certificate but not the intermediate. Some browsers have cached the intermediate from previous connections, so they work fine. Other clients (API consumers, mobile apps, command-line tools) that do not have the intermediate cached get a validation error. This is one of the most common TLS misconfigurations and is invisible to casual testing from a browser.
Expired certificate: Let's Encrypt certificates are valid for 90 days. A failed auto-renewal silently ticks down to expiration. Without monitoring, you find out when users see browser warnings.
Hostname mismatch: The certificate covers www.example.com but not example.com (or vice versa). Traffic to the uncovered hostname gets a TLS error.
Weak TLS version: The server still accepts TLS 1.0 or 1.1, which modern browsers are deprecating. While not a downtime issue, it is a security concern that monitoring can flag.

UptyBots provides dedicated SSL monitoring with multi-threshold expiration alerts. Set it up once and receive warnings well before a certificate expires.

7. How Does DNS Affect Uptime, and What Can Go Wrong?

Every HTTP or HTTPS connection begins with a DNS lookup. The client's stub resolver queries a recursive resolver (like 8.8.8.8 or 1.1.1.1), which queries your authoritative nameservers to resolve the hostname to an IP address. Only after obtaining the IP address can the client initiate a TCP connection.

DNS failures cause total outages that are particularly confusing to diagnose because the server itself is running fine. When DNS breaks:

Authoritative nameserver failure: If all your authoritative nameservers are unreachable (or return SERVFAIL), no new DNS queries can be resolved. Users whose resolvers have a cached record continue to work (until the TTL expires). Users without a cached record get immediate failures.
Registrar issues: Your domain's NS records (glue records at the registrar level) point to your authoritative nameservers. If the registrar has an issue, or if your domain expires, these NS records may be removed. The domain effectively ceases to exist in DNS.
Zone file errors: A syntax error in your DNS zone file can cause the authoritative server to stop serving the zone. Some DNS software rejects the entire zone on error; others serve a stale version. Either way, record updates stop propagating.
DNSSEC validation failure: If you use DNSSEC, a misconfigured signature (expired RRSIG, wrong key rotation) causes DNSSEC-validating resolvers to return SERVFAIL. Non-validating resolvers still work, creating a split where some users can reach you and others cannot.
TTL expiration during an outage: If your authoritative nameservers go down while DNS records are still cached, users are fine until the TTL expires. Once cache entries expire, resolvers attempt to refresh from the authoritative servers, fail, and return NXDOMAIN or SERVFAIL. Short TTLs mean a shorter grace period; long TTLs buy more time but slow down intentional changes.

Monitoring DNS independently from HTTP is valuable because a DNS failure presents differently than a server failure. An HTTP check that resolves via DNS might report "connection timeout" when the actual problem is DNS resolution failure. Knowing whether the issue is at the DNS layer or the server layer changes how you respond.

8. What Do Response Time Metrics Actually Measure?

When a monitoring service reports "response time: 340 ms," that number is the sum of several distinct phases, each involving different protocols:

DNS resolution (0-100+ ms): The time to resolve the hostname to an IP address. This depends on whether the monitor's resolver has a cached record, the location of the authoritative nameserver, and the number of CNAME or NS referrals involved.
TCP connection (1-200+ ms): The round-trip time for the TCP three-way handshake. This is a direct measure of network latency between the monitor and the server. A connection to a server on the same continent might take 10-30 ms; a cross-oceanic connection might take 150-250 ms.
TLS handshake (10-300+ ms): For HTTPS, the TLS negotiation adds one or two additional round trips (depending on the TLS version). TLS 1.3 requires one round trip for a new connection; TLS 1.2 requires two. Resumed sessions may use zero round trips (0-RTT in TLS 1.3).
Request transmission: The time to send the HTTP request from the monitor to the server. For a simple GET request, this is negligible. For large POST requests, it depends on upload bandwidth.
Server processing (1 ms to several seconds): The time the server takes to process the request and generate a response. This includes application logic, database queries, external API calls, and response rendering.
Response transmission (1-1000+ ms): The time to transfer the response body from the server to the monitor. For health check endpoints that return a small JSON body, this is negligible. For full HTML pages with images, it depends on response size and network bandwidth.

Good monitoring services break down the response time into these components (or at least distinguish DNS, connection, TLS, and server time). This breakdown is essential for troubleshooting. A slow response time could be a DNS issue (solution: reduce DNS chain length or use a faster provider), a network latency issue (solution: deploy closer to users or use a CDN), a TLS issue (solution: enable session resumption, upgrade to TLS 1.3), or a server processing issue (solution: optimize application code or database queries).

9. How Do Confirmation Checks Reduce Alert Noise?

A single failed check does not necessarily mean the service is down. Network protocols are inherently unreliable at the packet level. Packets get dropped, delayed, and corrupted on every network on the planet. The question is whether a failure is transient or persistent.

Confirmation checks work by requiring multiple consecutive failures before declaring a target down. The protocol-level mechanics:

Single-check failure: The SYN packet or HTTP request fails. This could be a transient loss, a monitoring node issue, or a real outage. At this point, the system schedules a confirmation check.
First confirmation: A second check runs (sometimes immediately, sometimes after a short delay). If this check passes, the initial failure is marked as transient and no alert fires. If it also fails, a second confirmation may be scheduled.
Multi-location confirmation: Instead of (or in addition to) temporal confirmation, the system triggers checks from other geographic locations. If Frankfurt reports a failure but Tokyo and Virginia report success, the failure is likely path-specific, not a genuine outage.
Alert fires: Only after the configured number of consecutive failures (or multi-location failures) does the system fire an alert. The downtime clock starts at the time of the first failed check, not the confirmation check.

The trade-off is detection speed vs. noise. Requiring three consecutive checks at 1-minute intervals means a real outage takes up to 3 minutes to generate an alert. For many services, 3 minutes of delay is acceptable in exchange for eliminating spurious alerts. For ultra-critical services (payment processing, emergency services), you might accept higher noise in exchange for faster detection.

UptyBots lets you configure the number of consecutive failures required before alerting, so you can tune the balance between speed and noise for each target independently.

10. What Does Domain Expiration Monitoring Check, and Why Does It Matter?

Domain expiration monitoring queries the WHOIS protocol (or RDAP, its modern replacement) to read the registration data for your domain. The key field is the expiration date (called "Registry Expiry Date" in WHOIS responses).

At the protocol level, WHOIS queries are simple: the monitor opens a TCP connection to port 43 on the appropriate WHOIS server, sends the domain name as a text query, and parses the text response. RDAP is a newer, RESTful protocol (HTTP-based, JSON-formatted) that provides the same information in a structured, machine-readable format.

Why domain expiration monitoring matters more than most people think:

A domain expiration takes down everything. Not just the website. Email, API endpoints, CDN origins, OAuth callbacks, webhook URLs, MX records for email delivery. Every service that depends on the domain name stops working.
Auto-renewal failures are common. Credit cards expire. Payment methods get removed. The billing contact leaves the company. The registrar's auto-renewal system has a bug. Any of these can cause a domain to expire despite the owner's intention to keep it.
Recovery is not instant. After a domain expires, it enters a grace period (typically 30-45 days) during which you can renew it at the normal price. After that, it enters a redemption period where the registrar charges a premium fee (often $100+). After redemption expires, the domain becomes available for anyone to register. Catching expiration early avoids all of this.
DNS propagation delays recovery. Even after you renew an expired domain, it takes time for DNS to propagate the restored records. Recursive resolvers that received NXDOMAIN responses during the outage may have cached that negative result, and the negative cache TTL (typically 300-3600 seconds, set in the SOA record) determines how long those resolvers continue to return NXDOMAIN after the domain is renewed.

UptyBots checks domain expiration daily and alerts at multiple thresholds (30, 14, 7, and 1 day before expiry). This gives you several chances to address a renewal issue before it causes an outage.

Frequently Asked Follow-Up Questions

What is the difference between an SLA and measured uptime?

Measured uptime is an empirical number: the percentage of checks that passed over a time window. SLA (Service Level Agreement) is a contractual promise, usually expressed as a minimum uptime percentage per month (e.g., 99.9%). SLAs include financial consequences (credits, refunds) for violations. Measured uptime from an external monitor is the evidence you use to determine whether an SLA was met, and it is independent of what the provider's own monitoring reports.

How accurate is uptime measurement from a single location?

It measures availability from that location's perspective, which is accurate for what it observes but incomplete as a global picture. A single location cannot detect regional outages affecting other areas. For business-critical services, multi-location monitoring provides a more representative measurement. Even two locations give you significantly better coverage than one.

Should I monitor the same endpoint with both TCP and HTTP checks?

For HTTP services, the HTTP check is sufficient because it implicitly tests TCP connectivity (the handshake must succeed before the HTTP request can be sent). Running both is redundant for the same endpoint. The exception is when you want to separately track network-layer reachability (TCP/ping) to distinguish "the network is down" from "the application is broken" in your alert analysis.

What happens if the monitoring service itself goes down?

During any period where the monitoring service is unable to reach the target, no checks are performed and no data is recorded. UptyBots runs distributed infrastructure with redundancy to minimize this risk. As an additional measure, you can use a second monitoring service as a cross-check for your most critical targets.

How do I migrate from another monitoring service to UptyBots?

Run both services in parallel for at least a week. Compare the uptime percentages and alert timing. If they produce similar results, you can decommission the old service with confidence. If the numbers differ significantly, investigate whether the difference is due to check type (TCP vs HTTP), timeout thresholds, or monitoring location differences.

Conclusion

Uptime monitoring is a protocol-level discipline. The numbers in your dashboard are the product of TCP handshakes, DNS lookups, TLS negotiations, and HTTP exchanges, each with its own failure modes. Understanding these mechanics lets you configure monitoring that accurately reflects user experience, set alert thresholds that match the real behavior of your network, and troubleshoot incidents faster because you know which layer failed.

UptyBots gives you the tools to monitor at each of these layers: HTTP for application health, TCP for port-level reachability, ping for network-layer connectivity, SSL for certificate validity, and domain monitoring for registration status. Set up the checks that match your architecture, tune the alerting to filter noise, and let the protocols tell you exactly what is happening.

Start improving your uptime today: See our tutorials or choose a plan.