Listening ports and connections

Every server running agent v1.5.0 or newer gets a Ports panel on its page, below Services. It answers two questions without an SSH session: “what is this server listening on?” and “how many clients are connected to each port?”. There is nothing to install or configure beyond the agent itself, and the panel fills in within a couple of minutes of the agent upgrading.

What the panel shows

Each listening TCP port is a row:

Column	Meaning
Port	The port number.
Service	The name your server’s /etc/services file gives the port (ssh for 22, https for 443), or — when it has none.
Scope	Local when the port accepts connections from the server itself only (loopback addresses), Exposed when it listens on any other address.
Connections	Established connections to the port, averaged over the last minute, with the busiest moment in brackets when it differs: 4 or 4 (peak 7).
Trend	A small chart of those connection counts over the range you are viewing.
Status	Listening, or Missing for 12m once the port has stopped listening.

The table shows the first 10 rows and a Show all link for the rest. Ports that went missing sort first and dim, so the one that needs a look is never hidden behind Show all. A missing port stays on the list for 25 hours, then drops off (one that listened for less than 10 minutes drops off at once).

A few details worth knowing:

• Connection counts cover the 30 lowest-numbered ports. The panel says so in its header: “Connection counts for the 30 lowest ports”. A server with more listeners than that still lists them (up to 1,000), but the ports beyond the cut can show — instead of a count, a scope, or a service name.
• Local versus Exposed is about the address a port listens on, not your firewall. A port reads Exposed when it listens on 0.0.0.0 or ::, even if a firewall blocks it from outside.
• A port is one row, whether it listens on IPv4, IPv6, or both.
• When a server’s last report is more than three minutes old, the header adds “Last update 12m ago” so stale rows don’t pass for fresh ones.
• On an agent older than v1.5.0 the panel says “Requires agent v1.5.0 or newer”; update the agent and the panel fills in. A current agent on a server with no TCP listeners shows “No listening ports reported”.

What is collected, and what is not

The agent reads the kernel’s TCP socket tables every 10 seconds and sends one summary per minute. Per listening port that is:

• the port number, the service name from /etc/services, whether it is local or exposed, and whether it listens on IPv4, IPv6, or both;
• the average and peak number of established connections to that port across the minute’s samples.

The agent never collects UDP ports, process names, process IDs, or command lines, and it never records local or remote addresses or who is connected. A connection is only counted against the port it arrived on. The field list is in What the agent collects; the agent itself still opens no listening ports of its own.

Container ports read near zero

The count is the number of connections the server’s own network stack holds open to the listening socket. Docker forwards outside traffic for a published port straight into the container, so the host’s listener (docker-proxy) sees almost none of it and the count usually reads near zero. The port is still listed, and the alert still works for it. A Kubernetes NodePort has no listener on the host at all, so it may not appear in the panel and the alert can’t watch it.

Get told when a port disappears

The Listening port disappeared rule, in the Ports group of the template editor, opens an incident when a port that had been listening stops. It is off by default in every template. To use it, open Alerts → Templates, click a template, and enable it.

• Window. The port must stay gone for the rule’s window before it fires. The default is 5 minutes and the dropdown goes up to 6 hours. A short window catches a crashed database quickly; a longer one rides out planned restarts.
• Only ports that had been listening for 10 minutes. A port that was up for less than that when it vanished (a test server you started and stopped, a short-lived job) disappears silently, with no incident.
• Agent outages don’t count. Only minutes in which the agent was reporting count toward the window, and a port still down when the agent returns starts its window over. While the agent is silent, port incidents neither open nor resolve; a long outage is what Agent offline reports.
• One incident per port, named after it: “Port 5432 has not been listening for 6 minutes”.
• Coming back resolves it. When the port listens again, the incident recovers and the usual resolve notice goes out after the 15-minute hold.
• Gone for good retires it. After 24 hours missing, the incident closes as Retired (“not seen for 24 h” in the incident list), with no resolve notice. A retired port does not alert again if the agent goes quiet and comes back afterwards.

The rule sits with the others in the alert rules reference. The panel works the same whether or not the rule is enabled.