Ports

Check that a TCP or UDP port accepts connections from every region you pick — optionally waiting for a banner or completing a TLS handshake.

How the port check works

A Port monitor connects to a host and port from each region you selected, on every check. The region results are combined as described in Core Concepts: the monitor goes down when more than half of its regions fail.

TCP

With Protocol set to TCP (the default), the check opens a TCP connection. The port is up as soon as the connection is accepted, unless the connection settings ask for more:

• Verify TLS handshake — after connecting, complete a TLS handshake. With Auto-detect (the default) this happens on well-known TLS ports: 443, 465, 563, 636, 853, 989, 990, 992, 993, 994, 995, 5061, 5986, 6697, 8443 and 9443. A handshake that fails or doesn't finish fails the check. The certificate is not judged: an expired or untrusted certificate still passes, and the monitor page shows the TLS version, cipher and whether the certificate is trusted. Use an SSL certificate monitor to be alerted on the certificate itself.
• Expect data on connect — wait for the server to send something, such as the greeting an SSH, SMTP or FTP server sends straight away. If nothing arrives before the timeout, or the server closes the connection without sending anything, the check fails.

A connection that is refused, can't be routed, or isn't answered within Connection timeout (10 seconds by default) fails. With Retry attempts set, a failed attempt is tried again — a second later, up to that many times — and only the last attempt's result is recorded. With the defaults (2 retries, 10 seconds), a port that never answers takes about 32 seconds to be reported down.

The response time recorded is the whole check: resolving the name, connecting, and the TLS handshake or the wait for data when those are on. The plain TCP connect time is kept separately and shown as Connect.

UDP

UDP has no connection to open, so the check resolves the host and sends a small datagram (the text Zharp UDP Check) to the port instead:

• With Expect data on connect set to No (the default), the check passes if the datagram could be sent and no “port unreachable” came back within half a second. A host that answers with “port unreachable” fails the check as refused. It doesn't prove anything is listening: many hosts and firewalls drop datagrams to a closed port silently, which looks exactly like an open one.
• With Expect data on connect set to Yes, the check passes only when a reply comes back before the timeout. Most UDP services, such as DNS and NTP, don't answer a datagram they can't parse, so this only works for a service that replies to arbitrary data.

Both protocols follow the monitor's IP version (under Advanced settings): IPv4 only or IPv6 only dial that address family, and IPv4 + IPv6 uses the first address the name resolves to.

Create a Port monitor

1. 1
   Choose the type

   On the Monitors page, click New, open the type picker and choose Port monitor. It is listed under Website & availability.

2. 2
   Enter the host and port

   Fill in Hostname or IP address, such as db.example.com or 203.0.113.10, and Port number (1 to 65535; the form starts at 80). Both are required. Put the port in its own field, not after the host.

3. 3
   Set the connection settings

   Open Advanced settings. In Connection settings, choose the Protocol, and whether the check should wait for data or complete a TLS handshake (see the table below).

4. 4
   Create it

   Pick who is alerted under How should we escalate incidents? and click Create monitor. If you leave the name empty, the monitor is named host:port.

Settings

A monitor created through the API without retryAttempts doesn't retry. Check frequency, Regions and the confirmation and recovery periods work as for every monitor; see Monitor Types.

When it goes down

Each check records the state the port was found in, and the message explains it. The addresses and names below are examples.

Internal addresses are refused when you save the monitor, and again at every check in case the name has since been pointed at one. To watch a service that is only reachable inside your network, see Private Networks.

The monitor page

A Port monitor's page shows:

• A bar with the protocol, host:port, the service that usually runs on that port (such as PostgreSQL for 5432 or SSH for 22) and the state of the last check: OPEN, REFUSED, TIMEOUT, UNREACHABLE, UNRESOLVED, NO DATA, TLS FAILED or ERROR (PENDING before the first check). A UDP monitor shows OPEN when the port replied, SENT when the datagram went out and nothing refused it, or NO REPLY. The bar also shows the timeout the check uses.
• A Connect time chart.
• Recent checks, with Status, Endpoint, Connect, State, Location (the region) and Date.
• Expanding a check shows the Resolved IP it connected to, the Connection timeout, what happened to the connection (for example SYN sent · RST received for a refused port), the DNS and connect times, and on a failure the error code. When a TLS handshake was made, a TLS panel shows the protocol, the cipher, whether the certificate is trusted and when it expires. For UDP, the row shows the datagram sent and whether a reply came back instead of the TCP handshake.
• The Port settings card, with the Resolved IP, Protocol, Port, Service, the Timeout, the check Interval and, for TCP, the TLS handshake setting with the last handshake's TLS version and certificate trust.

Troubleshooting

Refused or timed out — which is it?

refused means the host is reachable and actively said no: the service isn't running, it listens on a different port, or it only listens on 127.0.0.1 or a private interface. Check what is listening on the server (for example with ss -tlnp).

timeout means nothing answered at all. That is almost always a firewall that drops traffic from unknown addresses — a cloud security group, a host firewall, or an allowlist on the service. Zharp connects from each selected region, so the port must be open to the internet, not only to your office or VPN.

Only one region fails

A firewall or geo-block admits some regions and not others, or the route from that region is broken. While the other regions pass, the monitor stays up — its page shows the failing region, and nobody is alerted. Expand a failing row to see which region it came from.

The port is open but the check says No data received

Expect data on connect is on, but the service waits for the client to speak first. HTTP, PostgreSQL, MySQL and Redis all do. Set it to No, or use a website monitor or a Database monitor to check the service properly.

TLS handshake failed

The port accepted the connection but didn't speak TLS — or it expects a plain-text greeting first, as SMTP on port 587 does with STARTTLS. Set Verify TLS handshake to Never for those ports. Auto-detect only tries TLS on the well-known TLS ports listed above.

A UDP monitor is always up

Without Expect data on connect, a UDP check only shows that a datagram could be sent and wasn't refused, which is true whenever the host or a firewall drops it silently. Turn Expect data on connect on if your service replies to arbitrary data; otherwise monitor the service through a protocol-specific monitor.