How to Set Up a TCP Port Check (Full Guide)

Url / Domain / IP

Enter the target as host:port, for example example.com:22 for SSH or example.com:465 for SMTPS - the port is part of the address, not a separate field. You can also give the monitor a short name, which is what shows up in alerts, reports, and any status widgets.

Main Settings

There's no screenshot of this section for the Port check type specifically, but it uses the same Main Settings group as every other check type, so every control below is exactly what you'll see on the form:

• Monitoring enabled: pauses or resumes the check without deleting it.
• Interval schedule / Cron schedule: run on a fixed interval (the slider spans 1 minute up to 24 hours) or on a cron expression for a pattern the interval scale can't express.
• Tags: comma-separated labels for filtering and searching your monitor list. Organizational only - they don't affect the check itself.
• Full Log: saves every individual check result instead of grouping repeated identical results together.
• Open Stats: makes this monitor's statistics and log page shareable with people who aren't logged in to your account.
• Attached monitors - DNSBL: runs a DNS blacklist check against the same domain on its own 12-hour schedule, independent of the port-check interval. A detected bad state notifies according to the Down/Repeat subscriptions in Alert Subscriptions.
• Attached monitors - Web Risk: runs a Google Web Risk malware/phishing check against the domain, also on its own schedule. Gated by package.

Request Configuration

• Connect over TLS/SSL: off by default, meaning the check dials a plain TCP socket. Turn it on to wrap the connection in a TLS handshake before reading the response - the right choice for HTTPS-style services, SMTPS, or a database listener that requires TLS. Turning this on also reveals a TLS Handshake sub-group under Response Validation (below) with certificate validation policies. The on-screen note for this switch mentions "a plain TCP (or UDP) service", but there is no protocol picker anywhere in this form: every Port check dials TCP. If you need to monitor a UDP service, this check type doesn't currently expose that option.
• DNS Server Selection: the same dropdown used on other check types. Default DNS servers at locations resolves the host through each monitoring location's own public DNS servers, following local regulations. Public DNS resolves through a public DNS pool, with an optional list of excluded resolvers. Custom lets you supply your own DNS server IPs, one per row. On the account this screenshot came from, Public and Custom are both locked behind an upgrade banner, which is a package limit rather than a missing feature.

Response Validation

By default a check succeeds when the connection completes - and, when TLS/SSL is on, when the handshake also completes. The controls here let you require more than that:

• Response Pattern: an optional regular expression the response must match. When set, the check reads up to 1 MB of the TCP (or TLS, when enabled) response and fails when the pattern doesn't match; leave it empty to judge the connection alone. (Older documentation called this a "TCP response search pattern"; the current UI labels it Response Pattern.) Because only the first 1 MB is read, put the text you're matching near the start of what the service sends - a banner or greeting line works well; content the service sends later in a long response won't be seen.
• TLS Handshake (only visible when Connect over TLS/SSL is on): four independent switches judging the handshake itself. Require valid SSL certificate chain fails the check on an expired, self-signed, name-mismatched, or mis-chained certificate. Require strong TLS protocol (1.2 or higher) fails a server that only offers TLS 1.0/1.1 or SSL. Block weak ciphers (128-bit or lower) fails the check when the negotiated cipher suite is 128-bit or weaker. Check SSL certificate revocation does an online CRL/OCSP lookup during the handshake and fails on a revoked certificate; it's a separate package entitlement from the other three.
• Expected IPs Validation: turn this on to additionally require DNS to resolve your host to one of a list of IP addresses you specify, one per row. If the host starts resolving elsewhere - DNS hijacking, a stale record, a migration you forgot to update here - the check fails even though the new address still answers.

Alert Subscriptions

• Subscribe all contacts to Up/Down events: subscribes every contact on your account to both Up and Down alerts in one move.
• Down / Up / Repeat chips per contact: Down fires on a transition into a failing state, Up fires on recovery, and Repeat resends the Down notification on a schedule while the monitor stays down.
• Search contacts: filters the list by name or address.

Report Subscriptions

• Subscribe all contacts to Weekly/Monthly reports: subscribes every contact to both cadences at once.
• Daily / Weekly / Monthly chips per contact: choose which recurring uptime summary email each contact receives, separate from the real-time alerts above.

Monitoring Locations

• Location tree: pick which monitoring locations run this check, by continent, country, or all world; "Copy locations from another task" clones an existing monitor's set.
• Recheck strategy: how a state change gets confirmed. Default is a majority vote among recheck locations; alternatives are a specific number confirming Down (slider 1 to 7, matching the recheck pool size), no recheck at all, full agreement across all recheck locations, or full agreement for Down while Up only needs a majority.
• If selected locations are unavailable: "Selected locations only" (default) waits for a chosen location to come back; "Closest locations" reruns from the nearest available ones instead; "Any location" falls back to anywhere available worldwide.

Worked example

Monitoring an SMTPS mail relay on port 465: set Url / Domain / IP to mail.example.com:465, turn on Connect over TLS/SSL, and turn on Require valid SSL certificate chain plus Require strong TLS protocol under TLS Handshake so an expiring or downgraded certificate alerts you before customers notice bounced mail. Leave Response Pattern empty unless the service sends a recognizable banner you want to confirm. Pick three or four Monitoring Locations spread across regions, keep the default majority-vote Recheck strategy, subscribe your ops contact to Down and Up with Repeat turned on, and add a Weekly report subscription for a recurring uptime summary.

Troubleshooting

• No UDP option: despite the Connect over TLS/SSL tooltip mentioning UDP, this form only ever opens a TCP connection. If your target service is UDP-only, a Port check isn't the right tool for it today.
• Port reachable but check still fails with TLS on: check the TLS Handshake switches one at a time. A certificate that's technically valid but self-signed, or a server still offering TLS 1.0/1.1, will fail Require valid SSL certificate chain or Require strong TLS protocol respectively even though a plain connection would succeed.
• Response Pattern never matches: remember only the first 1 MB of the response is read. A pattern that only appears deep in a long response, or a service that sends a large payload before the text you're matching, will never match - keep the pattern to something the service sends early.
• Port blocked at the firewall, not the service: a check that fails even though the service works fine locally is often a security-group or firewall rule blocking that specific port from HostTracker's monitoring locations, not a service problem - confirm the port is open to outside traffic, not just that the process is running.
• Expected IPs goes stale after a migration: if you're using Expected IPs Validation and later move the service to a new host or IP, update the list - otherwise you'll get false Downs even though the service is reachable at its new address.

Related

• Distributed Availability Monitoring - the product page covering TCP Port checks.
• Free Port Check - test a host:port pair once, instantly, without creating a monitor.
• Ping Check: Full Setup Guide - the simpler reachability check when you don't need to test a specific port or service.
• Assertion Mode: Complete Response Validation Reference - the response-validation rule language used on other check types.
• How to check whether a port is open - the one-off version of this check, plus the nc and nmap commands behind it.
• All monitoring guides - the setup guide for every other check type.