Check reachability of your server using TCP handshake instead of ICMP.
⚠ Useful when standard ping is blocked by firewall or provider.
Helps detect service-specific downtime that ICMP ping cannot catch.

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.

Step 4

Switch the monitoring mode to TCP to check reachability by opening a real connection on a specific port. Unlike ICMP Ping, TCP checks verify that the service on the selected port is actively responding.

• Useful for web servers (HTTP/HTTPS), mail servers (SMTP/IMAP), databases (MySQL/PostgreSQL), and custom applications.
• Helps detect service-specific downtime that ICMP ping cannot catch.
• Requires specifying a valid port number to perform the TCP handshake.

👉 Make sure the chosen port is open and accessible from our monitoring network to receive accurate results.

Scan Frequency (Up/Down Monitoring)

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

The scan frequency determines how often your server or service port is tested for availability using a real TCP connection. Setting a shorter interval (e.g., 1 minute) allows you to detect service interruptions 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 checks are recommended for critical services (e.g., web, mail, database, or custom application ports) to ensure fast alerting.

Longer intervals (e.g., 1 hour or more) are suitable for less critical ports or services 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 port.

IP Protocols Settings

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

• IPv4 only – All TCP port checks will be performed using IPv4. Example: 1.2.3.4:80 (IPv4 address with port) will only allow IPv4 checks.
• IPv6 only – All TCP port checks will be performed using IPv6. Example: [2001:db8::1]:443 (IPv6 address with port) will only allow IPv6 checks.
• IPv4 + IPv6 (default) – Both protocols are supported, and monitoring will work for any valid domain with a port.

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

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

• Testing whether your service port is accessible via both protocols.
• Ensuring IPv6 readiness for specific services (e.g., HTTPS on port 443, mail on port 25).
• Debugging connectivity or firewall issues tied to one protocol type.

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

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.