Network uptime monitor for TCP ports and ping
A web page can load while the mail server refuses connections, the database port is closed or a VPN host drops half its packets. UptimePilot checks TCP ports and answers to ping from US East and EU Central, confirms every failure from a second region and alerts the right person by email, SMS, Slack, Microsoft Teams or webhook.
What a network uptime monitor watches
HTTP checks tell you a website answers. Many services that keep a business running never speak HTTP at all. Mail delivery, remote access, databases, caches and line-of-business applications listen on their own TCP ports, and some hosts only answer to ping. A network uptime monitor watches those layers directly, so you hear about a failure at the port, not three steps later when a customer cannot log in.
UptimePilot runs two network check types on every plan. A TCP port check opens a connection to a host and port and measures how long the handshake takes. A ping check sends ICMP echo requests and measures round trip latency and packet loss. Both run on the same schedule, the same alert rules and the same multi-region confirmation as every other monitor in your account.
- TCP port checks on any port from 1 to 65535
- Ping (ICMP) with round trip latency and packet loss per run
- Hostname or IP address as the target
- Checks every minute on Starter, every 30 seconds on Team and above
- Confirmation from a second region before a monitor is marked down
Common ports to monitor on servers and services
Most teams start with the ports that carry revenue or block work when they fail. Add each one as its own monitor, so an alert names the exact service that stopped.
| Port | Service | Why it is worth a monitor |
|---|---|---|
| 443 | HTTPS | The front door of every site and API, worth a port check next to the HTTP check |
| 80 | HTTP | Redirects to HTTPS and certificate renewals often depend on it |
| 25 | SMTP | Inbound mail between servers, a closed port means bounced mail |
| 587 | SMTP submission | Where your apps and staff send outgoing mail |
| 993 | IMAPS | Mailbox access for every mail client in the office |
| 22 | SSH | Remote administration and deploys |
| 3306 | MySQL | Application database, often reachable only from allowed addresses |
| 5432 | PostgreSQL | Application database, same allow-list rules apply |
| 6379 | Redis | Cache and queues, a closed port can stop background work |
| Custom | Any service | Game servers, VPN gateways, line-of-business apps, message brokers |
Databases and caches usually should not face the public internet. If yours are private, keep them private. Monitor the application in front of them with an api monitoring check, and watch the workers that depend on them with cron job monitoring heartbeats.
How a TCP port check works on UptimePilot
For each run, a probe resolves the hostname, opens a TCP connection and waits for the handshake to complete. A completed handshake means the port is open and something is listening. UptimePilot records the connect time in milliseconds, closes the connection and moves on. No data is sent to your service, so the check does not create sessions, log in or touch your application logic.
You set a timeout per monitor. The default is 10 seconds, which suits most services across regions. Lower it to 3 or 5 seconds for ports that should answer instantly inside a data center, and keep it longer for hosts on slow links. A connect time that crosses your threshold can raise a degraded state without marking the port down, so slow is visible before it turns into broken.
Closed port versus filtered port
The two failures look the same to a user and mean very different things to an engineer. UptimePilot reports them separately.
- Closed: the host answers and refuses the connection (a TCP reset). The machine is up, but nothing listens on that port. Usually a service crashed, failed to start after a reboot or was bound to the wrong interface.
- Filtered: nothing answers before the timeout. A firewall drops the packets, a security group changed, the host is down or the route is broken.
- Name resolution failed: the hostname does not resolve, which points at DNS, not at the server.
Knowing which of these happened tells the on-call person where to look first: the service, the firewall or DNS.
Ping monitoring with packet loss and latency
A ping check sends a short burst of ICMP echo requests per run and reports the share that came back and the round trip time. Packet loss is often the first sign of trouble on a network link, a saturated uplink or a failing interface, well before a host disappears completely. You choose the thresholds, for example degraded at 10 percent loss or 150 ms average round trip, and down at 100 percent loss.
Ping has one limit worth knowing. Many cloud hosts and corporate firewalls block ICMP on purpose. If a host never answers ping, use a TCP port check on a port that it serves instead. A port check proves more anyway, because it shows that a service is listening, not only that the network stack is alive.
Firewalls and allow-listing our probe addresses
Ports that are not public, such as SSH or a database restricted to known addresses, need an allow-list entry for UptimePilot probes. Your account shows the current list of probe IP addresses for US East and EU Central. Add them to the firewall or security group for the ports you monitor, and the checks reach the service while the rest of the internet still does not.
- Allow inbound TCP from the probe addresses to the monitored port only
- Allow ICMP echo from the probe addresses if you use ping checks
- Review the list in your account when you change firewall rules
- Keep a maintenance window on the monitor while you change rules, so scheduled work does not page anyone
Multi-region confirmation for network checks
A single probe can lose a route that has nothing to do with your server. UptimePilot checks from US East and EU Central, and a monitor is marked down only after a second region confirms the failure. A short routing problem between one region and your host is logged, not alerted. A real outage pages your team within one or two check intervals.
The incident log keeps every failed run with the region, the error type (closed, filtered, resolution failed, packet loss) and the timing, so the follow-up review starts from facts.
Alerts and escalation for network outages
Every plan includes email, Slack, Microsoft Teams and webhook alerts, plus SMS within the monthly allowance of the plan. Escalation sends the alert to the next person if nobody acknowledges it within the minutes you set. Group port and ping monitors per server or per client, so one alert rule covers the mail server, the database host and the VPN gateway together. More on channels and rules on the website downtime tracker page.
Pair network checks with server monitoring tools for heartbeats from backups and scheduled jobs, and with ssl certificate monitoring for the HTTPS endpoints on the same hosts.
Which plan fits network monitoring
Port and ping checks are included on every plan. The plans differ in volume, interval and team features. See all details on uptime monitoring pricing.
- Starter, $49 a month or $24 a month billed yearly: 50 monitors, checks every minute, 30 SMS alerts a month, 3 team members, 90 days of history
- Team, $99 a month or $49 a month billed yearly: 200 monitors, 30 second checks, 150 SMS alerts, 10 members, 1 year of history, monthly SLA PDF
- Business, $249 a month or $124 a month billed yearly: 1,000 monitors, 500 SMS alerts, 25 members, 2 years of history, white-label client reports and REST API
- Enterprise, $599 a month or $299 a month billed yearly: 3,000 monitors, 1,500 SMS alerts, 100 members, 3 years of history, SSO (SAML) and audit log
An IT team watching ten servers with four ports each fits Starter. An MSP covering dozens of client networks usually lands on Business.
01
Does a TCP port check send anything to my service?
No. The probe completes the TCP handshake, records the connect time and closes the connection. It does not send application data, log in or open a session.
02
Why does my host fail ping checks when it is clearly up?
Many hosts and firewalls block ICMP on purpose. Use a TCP port check on a port the host serves, which also proves that the service itself is listening.
03
Where do I find the probe IP addresses for my firewall?
Your account lists the current probe addresses for US East and EU Central. Allow them on the monitored ports, and on ICMP echo if you use ping checks.
04
How does UptimePilot tell a closed port from a filtered one?
A closed port answers with a reset, so the host is up and nothing listens. A filtered port gives no answer before the timeout, which usually means a firewall, a down host or a routing problem. The alert says which one happened.
05
Can I monitor database ports?
Yes, any TCP port. If your database is restricted to known addresses, add our probe addresses to the allow-list for that port only. Many teams prefer to keep databases private and monitor the application in front of them instead.
06
How fast will I hear about a closed port?
Within one or two check intervals, which is one to two minutes on Starter and 30 to 60 seconds on Team and above, once a second region confirms the failure.
Start watching your ports and hosts
Add a host, pick the ports, choose who gets alerted. Your first network uptime monitor runs a minute later.