TCP Port Monitoring: Watching Services Beyond HTTP

Why monitoring stops at the web layer

The common monitoring repertoire grew up around HTTP. A check calls an address, evaluates the status code, measures response time and fires when one of those falls outside the expected range. Every more advanced method builds on that: assertions in API monitoring for REST endpoints, recorded browser flows, checks of form journeys and login paths. These methods share one prerequisite that is rarely stated out loud: the service being checked has to speak HTTP. For a substantial part of a company's infrastructure, that is not the case.

A mail server accepts messages from other mail servers on port 25 (IETF RFC 5321) and messages from its own users on port 587, which has been the defined path for submission since 2011 (IETF RFC 6409). Retrieval runs over port 993 and submission with immediate encryption over port 465, both with a TLS connection established from the outset (IETF RFC 8314). An SSH service listens on port 22 and first exchanges a version string in the clear (IETF RFC 4253). Databases wait on port 3306 or 5432 (IANA), cache services usually on 6379. None of these services delivers a page that an HTTP call could fetch. Anyone who wants to monitor them has to work one layer lower - at the TCP connection itself.

The practical effect of this gap is uncomfortable: the visible part of the business, the website, is checked closely, while the invisible part - the one doing the actual work - runs unobserved. An outage there typically announces itself only when a customer calls or someone on the team notices that no enquiry has arrived since the morning. By then hours have usually passed in which no one received an alert, because no monitor existed for that service.

Which services live behind which ports

Port numbers are not arbitrary, they are administered. IANA maintains a registry of service names and port numbers that is split into three ranges: system ports from 0 to 1023, user ports from 1024 to 49151 and dynamic ports from 49152 upwards (IETF RFC 6335). The classic infrastructure services sit almost entirely in the first range, which makes monitoring easier - the target ports are known and rarely change. The overview below maps the most important ports to what their failure actually means day to day.

Two observations from this list matter in practice. First, far more than customer correspondence depends on the mail ports: password resets, invoice dispatch, contract confirmations and automated system messages all travel the same route. How to additionally secure and monitor the encryption of that route is described in the article on MTA-STS and TLS-RPT. Second, from a security standpoint the last two rows do not belong on the open internet at all - a point the article on the external attack surface of exposed services and the section further down both return to.

Open port, accepted connection, responding protocol

A TCP connection comes into being in three steps: the probe node sends a SYN packet, the service answers with SYN-ACK, the probe node confirms with ACK (IETF RFC 9293). Only then does the connection stand. What this sequence proves is routinely overrated in practice - it shows that a process on the target system holds the port and that the intermediate systems let the packet through. It does not show that this process is doing its actual job.

The difference matters as soon as something breaks. A security appliance can accept the connection on behalf of the service and discard it afterwards; an overloaded service can place connections in the accept queue without ever processing them; a mail server can complete the handshake and then reject every submission with a temporary error. In all three cases a plain port check reports success while the service is effectively down. It is therefore worth thinking of the check in levels and deciding per service which depth is appropriate.

What the time to connection setup reveals

Beyond the yes-or-no verdict, every port check yields a number: the time from the first packet to a standing connection. It is made up of name resolution, the travel time across the network path and the reaction time of the service. Add encryption and the process grows by the TLS handshake; with TLS 1.3 a single round trip is enough, whereas TLS 1.2 needed two (IETF RFC 8446). Anyone monitoring port 465 or 993 measures that share inevitably, because encryption there is set up right at connection time (IETF RFC 8314).

This number is the most useful early warning signal a port check produces. A service rarely fails from one minute to the next; more often it first becomes slow because connections pile up, memory runs short or a network path has been rerouted. What matters is not the mean but the distribution: a p95 value shifting from 40 to 900 milliseconds is a finding, even when the average barely moves. Why percentiles beat the average is explained in the article on p95 and p99 instead of the average.

A second benefit comes from comparing probe locations. If the connection time to the mail server stays stable at one location and rises many times over at another, the problem most likely does not sit in the service but on the way to it. That is exactly what checking from several locations is for: it separates the failure of a service from the failure of a route and keeps a disrupted network segment from being reported as a server outage.

When a port deliberately must not be public

Not every port that can be reached from outside should be. Database and cache services, admin interfaces, search indexes and message queues belong in an internal network or behind a secured gateway; the IT-Grundschutz modules consistently recommend exposing only the services that are genuinely needed (BSI IT-Grundschutz). The reason is not theoretical: in the Verizon Data Breach Investigations Report 2026, exploitation of vulnerabilities is the most common initial access path at 31 percent (Verizon DBIR 2026), an increase of 55 percent year over year (Verizon DBIR 2026); more than 22,000 confirmed data breaches across 145 countries were analysed (Verizon DBIR 2026). Every unnecessarily open service port enlarges that surface.

For monitoring this inverts the question. For a public service it reads: does it answer? For an internal service it reads: does it answer inwards - and stay silent outwards? Both checks make sense, but they measure opposite things. A port check from outside against port 3306 should fail; if it succeeds, that is a finding for the security side and not evidence of availability. This difference belongs in writing, otherwise the green indicator of such a monitor will be misread later on.

Availability of internal services can still be measured, just not from outside. The usual route runs via regular signs of life: a process on the system reports at a fixed cadence that it is running, and the absence of that report triggers the alert. That approach is described in the article on heartbeat monitoring for background processes. Anyone creating many service monitors should settle in parallel who may view and change them - which is where the article on access rights and an audit trail in the monitoring team comes in.

Check interval and the noise of connection timeouts

Port checks have a characteristic failure signature. Where an HTTP check usually returns a status code that hints at the cause, a failed TCP connection as a rule ends in a timeout with no further information. The reason lies in the protocol itself: if a SYN packet is lost, the system stack retries after a default wait of one second, doubling with every further attempt (IETF RFC 6298). In a widespread default configuration the attempt is retried six times, so connection setup is only finally abandoned after roughly 127 seconds (Linux kernel documentation).

For monitoring this means the check's own time limit is the decisive control, not the operating system's. A probe node that gives up after five seconds already reports an outage while the system stack is still patiently retrying. A limit set too short produces false alarms on every brief packet loss, one set too long delays the detection of genuine outages. It has proven useful to derive the limit from the observed connection time - roughly ten times the p95 value - rather than from a round number picked by gut feeling.

From this failure signature follows the second control: a single failed attempt is a weaker signal for port checks than for HTTP checks. Turning it straight into an alert produces up-down noise that wears the on-call rota down and buries real outages. A consensus across locations is more reliable: an outage counts as confirmed only once two of three probe nodes see it. How to damp this noise systematically is described in the article on taming flapping alerts; which detection time requires which interval is worked through in the article on choosing the check interval.

One last point concerns the other side. Repeated connection attempts from the same addresses look like a scanning attempt to some protection mechanisms, and an automatic block then hits your own monitoring of all things. The result is an outage that does not exist. The addresses of the probe nodes therefore belong on the exception list of protective systems - a task covered in detail in the article on the firewall whitelist for monitoring.

Setting up service monitors: a six-step approach

Theory turns into operational safety only once the checks move into fixed routines. A pragmatic approach that fits into a single afternoon:

1. Take stock of the services: note every service that can fail without the website noticing - mail submission and retrieval, SSH, databases, file handovers, cache and search services. Record for each one which port is responsible and whether it should be publicly reachable or not.
2. Decide the depth per service: for internal services a plain connection check is often enough, while for mail and handover services the level that reads the first protocol response is worth the effort. Write the decision down so it stays traceable later what a green tick at that spot actually says.
3. Derive time limit and interval from measurements: let the check run for a week before you set thresholds. Align the time limit with the observed p95 of the connection time and the interval with the detection time you need - for critical services, 60 seconds is a common starting point.
4. Require confirmation from several locations: set the alert threshold so an outage only counts once a second probe location has confirmed it. That costs a few seconds of detection time and, in practice, saves the bulk of false alarms caused by discarded packets.
5. Bundle the alert paths: route web and service checks into the same notification paths and escalation levels instead of running a second tool for infrastructure. An on-call rota that has to watch two separate inboxes will sooner or later miss one of them.
6. Keep and report the results: record availability and connection times per service over time so trends and achieved targets can be evidenced. How long that data may be kept and when it has to be deleted is covered in the article on a deletion policy for monitoring data.

Two neighbouring topics belong in the same round. First, releases regularly move ports, certificates and configurations without anyone updating the monitors; that stale intermediate states can also linger after a deploy is shown in the article on cache traps after the deploy. Second, every newly created service monitor should be given a named owner, otherwise a list of checks accumulates over the years that can no longer be attributed and whose alerts are therefore ignored.

Watching website and infrastructure in one account

The core of the task is unspectacular: the services that carry the business need the same attention as the page that presents it to the outside world. The effort involved is manageable - a handful of port checks, sensibly set time limits and one confirmation rule cover most of it. What makes the difference is bringing them together: one place for web and infrastructure, one alert path, one status page. Separate tools create separate responsibilities, and between two responsibilities the outage nobody expected tends to slip through.

Alongside HTTP and HTTPS, XICTRAQ also checks arbitrary TCP ports, and with them mail servers, SSH access, databases, file handovers and cache services. The checks run from three EU data centres, two of them in Germany and one in Finland; an outage counts as confirmed only once two of three nodes see it. For every monitor, name resolution, connection setup, TLS handshake and response time are kept as a time series and shown as percentiles, so a gradual degradation becomes visible. Planned work can be entered in advance as a maintenance window so that it does not trigger an alert.

The results flow into the same reports and onto the same public status page as the website checks - customers and colleagues see one picture instead of two separate tools. Start with the free trial and create your first port monitor for your mail server, or see in a personal demo how service and website monitors come together in one account.