Ping and Port Monitoring for Every Host You Run

Ping monitoring (ICMP)

Classic ping checks for servers and network devices that don't run a web server at all.

Choose a ping monitoring tool for the question it can answer: does the host reply to an ICMP echo request? A response confirms that the address is reachable from the checking location. It does not establish that SSH accepts logins, a database accepts queries, or a web application returns the right response.

ICMP monitoring is useful when the host itself is the subject of the check, rather than a particular service. For IP monitoring, be clear about which address represents the machine or device you intend to reach. An address that answers is not proof that every service behind it is working.

A route or firewall can stop replies from one network without taking the host offline. Checking from several places helps separate a local path problem from a host that cannot be reached. That distinction still requires investigation; an unanswered request does not identify the cause.

As often as every 60 seconds on paid plans, with longer intervals available on the free tier. See pricing when choosing a schedule.

TCP port monitoring

Monitor any service on any port — mail servers, databases, custom applications, game servers.

A TCP connection attempt confirms whether the destination accepts a connection on the selected port. Check the service's actual listening port rather than assuming its default is still in use. A firewall rule, a stopped daemon or a binding change can affect that result.

For SMTP monitoring, an open socket is only the first step: it does not prove that a message will be accepted or delivered. The same distinction applies to databases. A successful connection does not confirm credentials, a useful query result or the health of the application using that database.

Example service ports

An open port does not prove the application is healthy. Pair the connection check with server metrics to investigate the host's CPU, memory and disk and, for a website, website uptime monitoring to check the HTTP response. These signals answer different questions; one should not be treated as a substitute for all the others.

Need a one-off check? Use the free port checker.

Which check to use

Start with the operational question, not the protocol name. For host monitoring, decide whether you need evidence that an address answers, that a service accepts connections, or that an application returns the expected response.

An agent heartbeat answers another question: is the Linux server running and reporting metrics? Keep that signal separate from an external connection attempt. A machine can report internally while an outside connection fails, and a reachable address alone says nothing about the agent's reporting state.

Alerts when a host or port goes down

Give a ping alert an owner before relying on it. Use CloudStats server alerts for notifications, with email or a webhook as the destination. Keep the rule focused on a condition that needs a response rather than a message nobody is responsible for investigating.

A failed connection tells the responder where to start, not which firewall rule or process caused the problem. Check the host, the service and the path from the checking location before deciding what to change.