TCP monitoring: port availability checks (SSH, MySQL, Redis and more)

TCP monitoring is a check of a specific port over TCP instead of an HTTP request. Tracker.ru opens a TCP connection to the given host:port pair and records whether the handshake succeeded. If the connection fails to establish — the port is closed, the service is not listening, or the network is unreachable — the URL transitions to down and notifications are dispatched.

Unlike HTTP monitoring, there is no status code or response body here: the result is a binary signal, "the connection went through or it didn't." This is the most direct way to confirm that a background database, message broker, or SMTP server is in fact accepting incoming connections.

When to choose TCP over HTTP

TCP monitoring covers a class of tasks where an HTTP probe is either redundant or fundamentally inapplicable:

• Databases don't speak HTTP. MySQL on 3306, PostgreSQL on 5432, Redis on 6379, MongoDB on 27017 — each has its own binary protocol. An HTTP probe against these ports always returns an error; a TCP probe tells the truth.
• Queues and brokers. RabbitMQ (5672), NATS (4222) — same reasoning. A health check needs confirmation that the broker is listening on the port.
• gRPC and custom TCP services. Any binary protocol over TCP is checked exactly this way, without trying to parse an HTTP response.
• Mail services. SMTP (25, 587), IMAP (993), POP3 (995) — a TCP probe confirms that the mail server is up and listening on the corresponding port.
• Management ports. SSH (22), FTP (21), DNS (53). Especially useful after migrations, firewall changes, or instance replacement in the cloud.
• Edge case: HTTPS and SSH side by side. If a single server hosts both web (443) and SSH (22), a TCP probe on port 22 is the only way to detect that admin access is gone while the website still responds.

If you are dealing with a public website or a REST API, stay on HTTP monitoring: it gives you more information (status code, headers, optional keyword in the body, screenshots).

Supported ports

The UI and API support 16 presets from Url::TCP_PRESETS — the most common ports where explicit TCP monitoring makes sense. Any of them can be selected with one click, or you can enter an arbitrary number from 1 to 65535.

Ports 80, 443, and 8080 are intentionally on the list: sometimes you specifically need a TCP check (for example, to verify that nginx is listening on 443 after a restart) without a full HTTP request.

How to configure

In your dashboard click "Add URL" and switch the monitor type to TCP. The form will show host and port fields — enter a hostname without a protocol (db.example.com) and the port. The check interval and notification channels are configured the same way as for HTTP.

Via API:

curl -X POST https://tracker.ru/api/v1/urls \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "db.example.com",
    "monitor_type": "tcp",
    "port": 3306,
    "period": 60,
    "notify_telegram": true
  }'

The port field is required for TCP monitors (required|integer|min:1|max:65535); the protocol field is optional. The http_method and expected_keyword fields are ignored for TCP and should be passed as null or omitted.

Plan limits work exactly the same as for HTTP monitoring: a TCP check counts as a regular URL and consumes the plan's max_urls quota. The minimum check interval is determined by the plan.

What gets checked

The checker opens a TCP connection and waits for the handshake to complete. There are three possible outcomes:

• OK — the handshake succeeded, the connection is established. URL is up.
• tcp_refused — the port is closed (RST or connection refused received). Most often this means the service has crashed or is not listening on the port.
• timeout — the handshake did not finish within the timeout (60 seconds by default, adjustable via custom_timeout). Network blocking, a routing issue, or a heavily loaded server.
• host_not_found — DNS could not resolve the hostname. A typo, a deleted DNS record, or a resolver problem.

Each of these codes is written into check_log.error_status and used in the wording of notifications and in the URL log.

How TCP differs from HTTP

TCP monitoring is intentionally simpler than HTTP. What is not available for the TCP type:

• No HTTP status. The notification, instead of "Status: 500", carries the TCP error reason (tcp_refused, timeout, host_not_found).
• No body. Consequently, no keyword check — the expected_keyword field is ignored for TCP.
• No screenshots. Screenshots are taken by chromedp against an HTTP URL; a TCP service does not have a "page" that can be rendered.
• No SSL validation. A TCP handshake does not unwrap the TLS certificate. SSL checks (expiration, chain validity) are performed automatically only for HTTP/HTTPS checks. If you need to track a MySQL/Postgres certificate, add a separate HTTPS monitor against the public API of the same server.

In return, a TCP check:

• Is faster. A single SYN/SYN-ACK/ACK without sending or parsing HTTP.
• Is more reliable for non-standard protocols. It does not try to interpret the response — no false positives from a non-HTTP payload.
• Is cheaper for the service. Less load on the monitored server than a full HTTP request with headers.

Notifications

TCP monitors use the same channels and templates as HTTP: Telegram, MAX, Email, Webhook. The alert format reflects TCP specifics — instead of an HTTP code, the message prints the TCP error code and a textual description:

Site is unavailable! db.example.com:3306
Error: TCP connection refused
Down since 2026-05-01 19:15:09

The webhook payload contains an error_status field with the values tcp_refused, timeout, host_not_found — convenient for routing alerts in orchestration systems (PagerDuty, Opsgenie). Maintenance windows and recovery notifications work identically to HTTP monitoring.

Related articles

• /docs/features/keyword-check?lang=en — keyword check inside the HTML response for HTTP monitors.
• /docs/features/maintenance-windows?lang=en — maintenance windows: muting alerts during planned work.
• /docs/notifications/telegram?lang=en — Telegram notification setup.
• /docs/notifications/webhooks?lang=en — webhooks with HMAC-SHA256 signatures.