Easily check if your server or device is reachable with simple ICMP ping monitoring.
Quick to set up and effective for uptime checks.

Step 1

Open the dashboard, click the button, and select Ping Host from the dropdown menu.

Step 2

Choose whether to activate the monitor immediately or keep it paused for now:

• Active: The target is actively polled at the specified frequency to check its status.
• Paused: The target is temporarily inactive and will not be polled until set to active again.

Step 3

Set the Name and the Domain or IP (IPv4/IPv6) for your target. The Name will appear in alerts, reports, and notifications.

Scan Frequency (Up/Down Monitoring)

Your target will be pinged at a frequency of every 5 min by default. The minimum allowed frequency is 1 minute and the maximum is 24 hours.

The ping frequency determines how often your server or device is checked for reachability using ICMP. Setting a shorter interval (e.g., 1 minute) allows you to detect outages almost instantly. For free users, the minimum frequency is typically 5 minutes, while premium users can set it to 1 minute for near real-time monitoring. Frequent pings are recommended for critical servers and network devices to ensure fast alerting.

Longer intervals (e.g., 1 hour or more) are suitable for less critical devices where immediate notification is not required. Choose the frequency based on how quickly you need to respond to downtime and the importance of the monitored system.

IP Protocols Settings

You can choose which IP protocols to use when monitoring your target. By default, both IPv4 and IPv6 are allowed, and the monitoring bot will decide automatically which protocol to use.

• IPv4 only – All ping checks will be sent using IPv4. Example: 1.2.3.4 (IPv4 address) will only allow IPv4 pings.
• IPv6 only – All ping checks will be sent using IPv6. Example: [2001:db8::1] (IPv6 address) will only allow IPv6 pings.
• IPv4 + IPv6 (default) – Both protocols are supported, and monitoring will work for any valid domain.

👉 If you provide a direct IP address (e.g., 1.2.3.4 or [2001:db8::1]), the system automatically restricts monitoring to that protocol type (IPv4 or IPv6).

👉 For hostnames (e.g., example.com), you may explicitly choose to monitor only via IPv4 or only via IPv6. This can be useful for:

• Testing whether your server is reachable via both protocols.
• Ensuring IPv6 readiness before migration or deployment.
• Debugging connectivity or firewall issues specific to one protocol.

For most cases, we recommend keeping the default (IPv4 + IPv6) setting, ensuring maximum compatibility and availability.

How would you like to be notified?

By default, all available notification channels are enabled:

• On the website / In-app
• Email
• Telegram
• Webhook

You can customize which channels to use for this monitor individually, or globally manage permissions for Email, Telegram, and Webhook notifications via your Notification Channels settings.

✅ Recommended: Keep all channels enabled for maximum awareness of uptime issues, but adjust according to your preferences and workflow.

The Most Fundamental Reachability Check

ICMP ping is the simplest possible network reachability test. It sends a tiny packet to the target and waits for a response, telling you whether the host is alive at the most basic network layer. Unlike HTTP or API monitoring, ping does not depend on application code, web servers, or any specific service running — it only tests whether the operating system on the other end can respond to a network packet.

This makes ping monitoring ideal for tracking the health of routers, switches, firewalls, network appliances, IoT devices, VPN gateways, and any other infrastructure where you care about basic reachability rather than specific service health.

When Ping Is Enough — and When It Is Not

Ping is perfect for telling you that a server has crashed, lost network connectivity, or had its IP routed away. It is fast, lightweight, works through almost any network, and gives you a clear binary answer: alive or dead.

However, a server can respond to ping while its actual application is broken. The web server might be hung, the database might be down, the API might be returning 500 errors — but ping will still report "up". For full service health, combine ping monitoring with HTTP, API, or port monitoring on the same host. Ping is the foundation, not the whole house.

Network Infrastructure

Ping is the standard way to monitor routers, switches, firewalls, and load balancers. These devices typically do not run web services you can monitor with HTTP, but they all respond to ICMP. A failed ping check on your edge router is often the first sign of an upstream network outage.

For multi-site organizations, ping monitoring across all office locations helps you detect site-to-site VPN failures and ISP outages quickly.

Bare Metal and Virtual Machines

Use ping to verify that your servers are alive at the network level, separate from any application health. If a server stops responding to ping, you know there is a hardware, hypervisor, or network issue — not just a crashed process.

This is especially valuable in cloud environments where you want to detect instance failures, network attachment issues, and security group misconfigurations.

IoT Devices and Edge Hardware

IoT devices, IP cameras, smart home hubs, and edge computing nodes often do not run conventional web services, but they all need to be online to do their job. Ping monitoring lets you track their availability without requiring custom integrations.

For deployments with hundreds of devices, ping monitoring is the only practical way to track which ones are reachable at any given moment.

VPN and Remote Access Verification

After establishing a VPN connection, the most reliable way to confirm it is working is to ping a known host on the other side. Continuous ping monitoring of internal hosts behind your VPN gateway tells you immediately if the tunnel goes down, even if no users are actively connected.

Some Hosts Block ICMP Entirely

Many cloud providers, hosting platforms, and security-conscious networks block ICMP traffic at the firewall or load balancer level. A host that blocks ICMP will appear "down" in ping monitoring even if the actual services are healthy and reachable on other ports.

Before relying on ping monitoring, manually verify that the target responds to ICMP from outside your network. If it does not, use port-based or HTTP monitoring instead.

ICMP Has Lower Priority on Many Networks

Routers and load balancers typically deprioritize ICMP traffic compared to other protocols. During heavy load, you may see slightly higher ping latency or occasional dropped packets even when actual application traffic is fine.

This is normal and not a sign of a real problem. Configure your monitoring to tolerate occasional missed pings before raising an alert, so you do not get woken up by transient network conditions that have no real impact.