Service Availability (TCP) Monitoring
Service Availability (TCP) Monitoring
Verify that TCP-based services and ports are open and responsive. Cloudmon tests connection success, measures response time, and tracks availability for any service from standard ports like HTTPS and SSH to custom application endpoints.
Overview
Service/Port Availability monitoring in Cloudmon tests whether a specific TCP port on a host is open and accepting connections at every polling interval. Unlike Host Availability which only checks whether a host is reachable, Port Availability verifies that a specific service is running and responsive. A server can be online and responding to ICMP pings while a critical service on that server has crashed and its port is closed. Port Availability catches this immediately.
Cloudmon measures TCP connection success, the time taken to establish the connection (response time), and tracks availability as a percentage over time. Rising connection times indicate service degradation before full failure. If the port is closed or the connection times out, the service is marked as down and an alarm fires according to the configured rule.
Port monitors can be added manually or discovered automatically via Network Discovery using the Service type with TCP protocol.
Configuration
To add a port monitor manually, navigate to Synthetic → Network → Service Availability and click the + button. The Add/Edit panel is organized into three sections: Monitor Details, Configuration Details, and Alert Settings.
Monitor Details: basic identification details for this monitor.
| Field | Description |
| Probe* | The Cloudmon probe that will test the TCP connection. Choose a probe with network access to the target host and port. |
| Display Name | A descriptive name for this monitor, such as "Production Web Server HTTPS" or "Payment Gateway API Port". |
| Hostname or IP* | The IP address or hostname of the server running the service to be monitored. |
| Service | Select a named service from the dropdown, such as HTTP (80), HTTPS (443), SSH (22), or FTP (21). Custom port numbers can also be entered for application-specific services that do not use standard ports. TCP is the only protocol used for port monitoring. |
| DSCP | An optional DSCP (Differentiated Services Code Point) value from 0 to 63, used to mark outgoing packets for QoS-aware network handling and prioritization. |
Configuration Details: polling, reporting, and grouping settings.
| Field | Description |
| Polling Interval* | How frequently Cloudmon attempts the TCP connection. |
| Reporting Interval* | How frequently the polled statistics are aggregated and reported. |
| Depends On | Link to an upstream dependency monitor. If the dependency is down, alerts from this service monitor are suppressed to prevent cascading alarm noise. |
| Tags | Optional labels for filtering and grouping this monitor in dashboards and reports. |
Alert Settings: configure alerting rules for this monitor.
| Field | Description |
| Alarm Rule | Select an alarm rule to apply to this service monitor. |
| User Groups | The user groups that should be notified when an alarm is raised for this monitor. |
| Third Party Services | Third-party integrations (such as Slack, Teams, or ITSM tools) to notify when an alarm is raised for this monitor. User Groups and Third Party Services set here at the monitor level are automatically inherited by the attached alarm rule. |
Click Save. Cloudmon begins testing the port at the configured interval immediately.
What Cloudmon Monitors
For each monitored service, Cloudmon tracks availability as a percentage of intervals in which a successful TCP connection was established, response time as the time in milliseconds to complete the TCP handshake, downtime duration when the port was unreachable or refused the connection, error rate as the percentage of failed connection attempts, and jitter as the variation in response time between polling intervals.
Trace Path
A Network Path view is also available for each port monitor, showing the hop-by-hop route from the probe to the target service. This helps isolate whether a service slowdown originates at the server itself or at an intermediate network hop. To enable it, navigate to the service monitor's Settings tab, toggle Trace Path on, set the interval, and click Save.
Alarms
Each alarm is built around a simple IF/THEN model, where you select a metric, set a threshold, and define what happens when it is breached. Alarm rule profiles are created under Settings → Configurations → Alarm Rules, then attached to a service monitor by selecting the profile from the Alarm Rule field under Alert Settings. The User Groups and Third Party Services assigned in the same section are inherited automatically by the attached alarm rule. Learn more.
Troubleshooting
| Issue | What to check |
| Port shows as down but the service is running | Confirm that the firewall or security group between the probe and the target server is not blocking the monitored port. Test manually from the probe host using telnet or netcat to the target IP and port. If the connection is refused, the port is genuinely closed from that network path even if the service is running and listening on a different interface. |
| Response time is high but the port is reporting as up | Enable Trace Path on the service monitor to identify whether the latency is in the network path or at the server. A slow TCP handshake that completes eventually indicates a congested or overloaded server, not a network problem. Check the target server's CPU and connection queue depth. |
| Custom port added but shows connection refused immediately | Verify the application is actually listening on that port by running netstat or ss on the target server. Confirm the correct port number was entered and that the application service is running. A connection refused response means the port is reachable but no process is accepting connections on it. |
| Monitor shows intermittent up and down flapping | Flapping typically indicates a connection timeout rather than a clean refusal, suggesting the probe can reach the host but the service is occasionally not responding within the timeout window. Increase the Connection Timeout value in the monitor settings or investigate application-level connection queuing on the target server. |