Network Uptime Monitoring with TCP and DNS Checks 2026

HTTP monitoring covers the most visible layer of your infrastructure — the web endpoints users interact with directly. But a significant portion of what keeps a production system running isn't HTTP: database ports, VPN gateways, SMTP servers, LDAP directories, DNS resolvers, and countless other TCP-based services form the connective tissue of modern applications. When these fail, applications break in ways that HTTP endpoint checks alone won't detect.

This guide covers TCP port monitoring, DNS resolution checks, ICMP availability testing, and how to use Vigilmon's TCP monitors to build coverage for the parts of your infrastructure that sit below the HTTP layer — VPN endpoints, database ports, mail servers, DNS infrastructure, and more.

What You Can Monitor Without HTTP

HTTP monitoring assumes a service that speaks the HTTP protocol — a web server, an API gateway, a load balancer. Many critical infrastructure components don't use HTTP at all, or expose HTTP only for management while their operational protocol is something else entirely.

TCP Port Checks

TCP port monitoring establishes a connection to a host and port, confirming:

The host is network-reachable (routing is working)
Something is listening on the port (the process is running)
The connection is accepted (no firewall is blocking the port)

A successful TCP connection takes 3–50ms on a healthy service. A timeout or connection refused immediately indicates a problem — either the service is down, the process has crashed, or a firewall rule has changed.

TCP port monitoring does not inspect the protocol payload. It confirms reachability and listener availability, not application-level correctness. This makes it faster and lighter than HTTP checks, and applicable to any TCP-based service regardless of protocol.

DNS Resolution Monitoring

DNS is foundational infrastructure. If your DNS resolver fails, nothing else works — even services that are fully operational will appear unreachable because their names can't be resolved to IP addresses.

DNS monitoring validates:

Authoritative DNS: Your domain's nameservers return correct records for your domain names
Recursive resolvers: Your application's configured DNS resolvers are functioning
Record integrity: A records, CNAME records, MX records, and others resolve to expected values
Resolution latency: DNS lookup time (slow DNS degrades all application response times)

ICMP Ping

ICMP ping confirms that a host is network-reachable at the IP layer. It's the most basic reachability check: if a ping succeeds, the host is up and routing is functional to that address.

ICMP monitoring is appropriate for:

Network devices (routers, switches) that don't expose HTTP endpoints
Hosts where you want to confirm the OS is running but don't have a service endpoint to check
VPN tunnel endpoints (pinging across the tunnel confirms the tunnel is up)

Note: Some hosts and network devices drop ICMP by firewall policy even when the host is fully operational. ICMP monitoring should be combined with TCP monitoring where possible.

TCP Port Monitoring by Service Type

VPN Endpoints

VPN gateways expose TCP or UDP ports for their connection protocols. TCP-based VPN protocols are directly monitorable with TCP port checks:

| VPN Protocol | Default Port | TCP Check | |---|---|---| | OpenVPN (TCP mode) | 1194 | ✅ | | WireGuard management API | varies | ✅ (if exposed) | | Cisco AnyConnect / SSL VPN | 443 | ✅ | | Fortinet FortiClient | 443, 8443 | ✅ | | OpenVPN Access Server (web UI) | 943 | ✅ |

What TCP monitoring of VPN endpoints catches:

VPN daemon crashes (port closes, connections refused)
Firewall changes that accidentally block the VPN port
Server reboots where the VPN service didn't auto-start
Load balancer misconfiguration routing VPN traffic incorrectly

Vigilmon TCP monitor setup for OpenVPN:

Create a TCP monitor targeting vpn.yourcompany.com:1194
Set check interval to 1 minute
Alert routing: PagerDuty (VPN down = remote workers and branch offices are affected)

Database Ports

Database availability is often only confirmed when an application tries to use it. TCP monitoring lets you detect database failures before applications fail.

| Database | Default Port | |---|---| | PostgreSQL | 5432 | | MySQL / MariaDB | 3306 | | MongoDB | 27017 | | Redis | 6379 | | Microsoft SQL Server | 1433 | | Oracle Database | 1521 | | Elasticsearch | 9200 | | CockroachDB | 26257 |

Important note: Monitor the database port from your monitoring infrastructure's vantage point. If your database is inside a private network and not internet-accessible, Vigilmon's public probe nodes cannot reach it. For private database monitoring, consider exposing a health check HTTP endpoint from your application layer that checks database connectivity, rather than exposing the database port directly.

For internet-accessible databases (hosted database services, publicly exposed read replicas, or databases in DMZ environments), Vigilmon TCP monitors confirm reachability directly.

Vigilmon TCP monitor setup for PostgreSQL (internet-accessible):

Create a TCP monitor targeting db.yourcompany.com:5432
Set check interval to 1 minute
Alert: immediate notification — database down means application down

SMTP and Mail Servers

Email infrastructure uses several TCP ports, each covering a distinct delivery role:

| Service | Port | Protocol | |---|---|---| | SMTP (submission) | 587 | STARTTLS | | SMTP (direct) | 25 | SMTP | | SMTP over TLS | 465 | SMTPS | | IMAP | 143 | IMAP | | IMAP over TLS | 993 | IMAPS | | POP3 | 110 | POP3 | | POP3 over TLS | 995 | POP3S |

TCP monitoring confirms that your mail server is accepting connections. A failed TCP check to port 25 or 587 means your outbound mail delivery is broken — transactional emails, password resets, and notifications won't be delivered.

Vigilmon TCP monitor setup for a self-hosted mail server:

TCP monitor: mail.yourcompany.com:587 (submission port)
TCP monitor: mail.yourcompany.com:25 (direct delivery)
HTTP monitor: https://mail.yourcompany.com/health (if your mail server exposes one)

For services using Postfix, Exim, or Stalwart Mail, TCP port monitoring catches process crashes and port binding failures immediately.

LDAP and Directory Services

LDAP directories (Active Directory, OpenLDAP, FreeIPA) are critical identity infrastructure. If LDAP is unreachable, authentication fails across all services that delegate to it.

| Service | Port | Protocol | |---|---|---| | LDAP | 389 | LDAP | | LDAPS | 636 | LDAP over TLS | | Active Directory Global Catalog | 3268, 3269 | LDAP | | Kerberos | 88 | TCP/UDP |

A TCP monitor on port 389 or 636 confirms that the LDAP listener is accepting connections. If your LDAP server is accessible from your monitoring infrastructure, this catches directory service failures before they cascade into application authentication failures.

SSH Servers

SSH port monitoring confirms that your server management access is intact:

TCP monitor: your-server.com:22

An SSH port going unreachable is an early indicator of a serious problem — the server is network-isolated, a firewall change blocked port 22, or the SSH daemon crashed. Catching this before you need emergency access is much better than discovering it when you try to log in.

DNS Monitoring

Why DNS Monitoring Is Often Overlooked

DNS failures are acute and total: when DNS breaks, nothing that uses domain names works. Yet DNS monitoring is often skipped because DNS "usually just works" — until it doesn't.

Common DNS failure modes:

Nameserver outage: Your domain's authoritative nameservers go offline (hosting provider failure, DDOS, misconfiguration)
Record propagation failure: A DNS record update fails to propagate to all nameservers, causing split-horizon resolution where some users see old records
Zone transfer failures: Secondary nameservers stop receiving zone transfers from the primary, serving stale records
Resolver failure: Your application's configured DNS resolver stops working (affects only services using that resolver)
Record misconfiguration: An incorrect record is published — wrong IP, wrong CNAME target, missing MX record — causing a subset of DNS-dependent functions to fail

DNS Monitoring Approaches

HTTP monitor on root domain: The simplest DNS check. If https://yourcompany.com resolves and returns 200, DNS for your primary domain is functioning. This is implicit DNS monitoring — the HTTP check can't succeed unless DNS works.

TCP monitor with hostname (not IP): A Vigilmon TCP monitor targeting db.yourcompany.com:5432 must resolve the hostname before connecting. If this check fails while a check against the raw IP succeeds, DNS is the failure layer.

Dedicated DNS checking: For DNS infrastructure you own and operate (your nameservers, your internal resolver), dedicated DNS monitoring tools that query specific records and validate responses give more granular visibility. Vigilmon complements this with TCP monitoring of DNS server ports (port 53 TCP) to confirm listener availability.

MX record monitoring via SMTP TCP check: If your SMTP TCP monitor (mail.yourcompany.com:25) succeeds, DNS MX record resolution is also working — the hostname resolved to reach the port. A failure could be either DNS or the mail server itself; investigating which is a diagnostic step.

Network Device Availability

For network devices that don't expose web services — routers, switches, firewalls — monitoring options beyond SNMP (which requires an inside-network poller like LibreNMS or Zabbix) are limited but still valuable:

Management Interface HTTP/HTTPS

Most modern network devices expose web-based management interfaces:

Ubiquiti UniFi: https://192.168.1.1 or UniFi controller
pfSense / OPNsense: https://192.168.1.1
Cisco ASA ASDM: https://firewall-management.internal
MikroTik Winbox web: http://192.168.88.1

If your monitoring infrastructure can reach the management interface, an HTTP monitor confirms the device is reachable and its management service is running.

SSH Port on Network Devices

Many routers, switches, and firewalls expose SSH for management. A TCP monitor on port 22 confirms the device is reachable and accepting management connections.

SNMP Port (TCP 161/162)

Some SNMP implementations bind to TCP in addition to UDP. A TCP port 161 check confirms the SNMP agent is listening.

Using Vigilmon TCP Monitors for Infrastructure Beyond Web Services

Vigilmon's TCP monitoring is straightforward to configure and covers any TCP-accessible service.

How Vigilmon TCP Checks Work

Vigilmon's probe nodes attempt to establish a TCP connection to the configured host and port
The connection handshake confirms reachability (SYN → SYN-ACK → ACK)
If the connection succeeds, the check passes
If the connection is refused, times out, or encounters a network error, the check fails
The result from multiple geographically distributed probe nodes is compared — failure is only confirmed when a quorum of probes agree (eliminating single-probe false positives)

TCP Monitoring Configuration Checklist

For each service you want to monitor via TCP:

Identify the host and port: The accessible hostname or IP, and the service port
Verify network accessibility: Confirm the port is reachable from the internet (or from your monitoring infrastructure's location) — Vigilmon's public probes cannot reach private network services
Set check interval: 1 minute for critical services, 5 minutes for lower-criticality services
Configure alerts: Route critical service failures (database, VPN, mail server) to immediate notification channels
Document expected state: Note whether a TCP connection success means a process is running (most cases) or just that a port is open (firewall passthrough with no listener)

A Complete Infrastructure TCP Monitoring Setup

# Critical services - 1 minute interval
VPN endpoint:      vpn.yourcompany.com:1194       → PagerDuty
SSH management:    bastion.yourcompany.com:22     → PagerDuty
Mail server SMTP:  mail.yourcompany.com:587       → PagerDuty
LDAP directory:    ldap.yourcompany.com:636       → PagerDuty

# Application infrastructure - 1 minute interval
Database primary:  db-primary.yourcompany.com:5432 → PagerDuty
Redis cache:       cache.yourcompany.com:6379      → PagerDuty

# Supporting services - 5 minute interval
Mail IMAP:         mail.yourcompany.com:993        → Slack #ops
Backup SSH:        backup.yourcompany.com:22       → Slack #ops
Dev database:      db-dev.yourcompany.com:5432     → Email

Network Device Availability vs. Service Availability

An important distinction when designing your TCP monitoring coverage:

Network device availability answers: "Is this router/switch/firewall reachable?"
Service availability answers: "Is this service accepting connections on this port?"

A database server might be reachable at the network layer (ping succeeds, SSH works) while the database process has crashed (port 5432 refuses connections). A router might respond to SNMP (visible to LibreNMS) but have a misconfigured ACL that blocks port 587 traffic (invisible to SNMP polling, visible to a TCP monitor from outside).

The outside-in TCP check from Vigilmon's probes tests the exact path that your application traffic follows. It catches the class of problems that inside-out tools miss: firewall rule changes, load balancer misconfiguration, routing anomalies that affect external traffic but not internal traffic, and service process crashes.

Complementing TCP Monitoring with HTTP Monitoring

The strongest monitoring coverage combines TCP and HTTP checks:

TCP check: Confirms the port is reachable and a listener is present
HTTP health check: Confirms the application is healthy, not just listening

For a database-backed API, a complete monitoring setup might include:

TCP monitor on the database port (confirms the database process is running)
HTTP monitor on the API's /health endpoint (confirms the API can connect to the database and serve requests)
Heartbeat monitor for the nightly backup job (confirms the scheduled task completes)

Each layer catches different failure modes. The TCP database check catches process crashes before any HTTP check would see symptoms. The HTTP health check catches application-layer failures (misconfigured credentials, connection pool exhaustion) that leave the TCP port up but the service degraded.

Conclusion

HTTP uptime monitoring covers the visible surface of your infrastructure. TCP monitoring covers the infrastructure layer beneath it — the database ports, VPN endpoints, mail servers, LDAP directories, and DNS listeners that HTTP checks miss entirely.

Vigilmon's TCP monitors work the same way as HTTP monitors: multi-region probe nodes, consensus confirmation before alerting, and flat-rate pricing per monitor. Adding TCP coverage to your Vigilmon setup takes minutes per service and closes the monitoring gaps that exist in pure HTTP-focused uptime monitoring.

Try Vigilmon free at vigilmon.online — TCP port monitoring, HTTP uptime checks, and heartbeat monitoring in a single dashboard, multi-region consensus alerting, free tier permanent with no credit card.

Tags: #tcpmonitoring #networkmonitoring #uptime #dns #smtp #vpn #database #vigilmon #devops #sre #infrastructure #2026