# Checkly TCP Port Monitoring

**Source**: https://www.checklyhq.com/product/tcp-monitoring/

> Databases, message queues, mail servers, custom services. A TCP monitor connects to host:port from 22 public locations or inside your own network, optionally sends data, and asserts on the response and the response time. Defined in TypeScript, deployed from CI, alerting built in.

## TCP monitoring as code

- **A connection is not enough**: a port that accepts a SYN can still be a dead service. Send a payload after the handshake and assert on what comes back: a PONG, a 220 banner, your own health string.
- **Latency, split into phases**: every run records DNS lookup, TCP connect, and data transfer separately, per location. Degrade at one threshold (`degradedResponseTime`, default 4000 ms), fail at another (`maxResponseTime`, default 5000 ms).
- **Public edge or inside the VPC**: run from 22 public locations, or from a Checkly Agent private location for the databases and brokers that were never meant to face the internet.
- **Verify a port is closed**: enable "this request should fail" and a refused connection or timeout passes, so firewall rules and security groups are proven from 22 vantage points.
- **TCP monitoring as code**: the `TcpMonitor` construct with `TcpAssertionBuilder` in the Checkly CLI. Run `npx checkly test` in CI, then `npx checkly deploy`.

## What teams monitor over TCP

- **Databases**: confirm Postgres, MySQL, or MongoDB accepts connections from outside the app tier, and how long the handshake takes from each region.
- **Caches and message queues**: send PING to Redis and assert on PONG. Verify RabbitMQ or Kafka brokers are listening.
- **Mail servers**: open SMTP submission or IMAPS, assert the 220 greeting arrives, and watch response time.
- **Custom TCP services**: anything that speaks a line protocol.
- **Firewall and network rules**: prove a port that must stay closed to the public still is.
- **Internal services**: run the same monitor on a Checkly Agent inside your VPC.

## Key facts

- Assertions: response time (`lessThan`, `greaterThan`) and response data (`contains`, `notContains`).
- Frequency from **every 10 seconds to every 24 hours**, subject to the plan minimum. **22 public locations** or private locations (Team and Enterprise).
- IPv4 by default, IPv6 supported via `ipFamily`.
- Honest limit: some public locations run on AWS, which blocks outbound port 25. Monitor SMTP on 587 or 465, or from a private location. For plain host reachability, Checkly also has ICMP ping monitors.
- Priced per monitor, not per run: **10** uptime monitors on Hobby, **50** on Starter, **75** on Team, custom on Enterprise, with more in blocks of 25.

## Customer quote

> "TCP checks are working nicely for our use case. We're using them to monitor some of our critical network services."
> Matt Watkins, Release Engineering Team, The Linux Foundation

## Frequently Asked Questions

### What is TCP port monitoring?
TCP port monitoring opens a TCP connection to a hostname and port on a schedule and records whether the connection succeeded and how long it took. Checkly TCP monitors go one step further: they can send data after the handshake and assert on the response, so you know the service behind the port is answering, not just that something is listening.

### Which services can I monitor with a TCP monitor?
Anything that listens on a TCP port: Postgres, MySQL, and MongoDB databases, Redis, RabbitMQ and Kafka brokers, SMTP and IMAPS mail servers, FTP, SSH, and your own line-protocol services. For HTTP endpoints use a URL or API monitor, for DNS records a DNS monitor, and for plain host reachability an ICMP monitor.

### What can a TCP monitor assert on?
Two things. Response time, with lessThan and greaterThan thresholds in milliseconds, and response data, with contains and notContains matches on whatever the server sends back after your optional payload. You also set two thresholds per monitor: degradedResponseTime (default 4000 ms) marks a run degraded, maxResponseTime (default 5000 ms) fails it.

### How often can a TCP monitor run, and from where?
From every 10 seconds to once every 24 hours, subject to the minimum interval on your plan. Monitors run from any of 22 public locations across the Americas, Europe, the Middle East, Africa, and Asia Pacific, or from private locations on your own infrastructure (Team and Enterprise plans).

### Can I monitor a database or broker that is not exposed to the internet?
Yes. Install the Checkly Agent inside your network as a private location and assign the monitor to it. The agent runs the TCP connection from inside your VPC and reports results back to Checkly, so nothing has to be opened to the public.

### Can I verify a port is closed?
Yes. Enable "this request should fail" on the monitor and connection failures such as timeouts and refused ports count as passed, while a successful connection still passes. Only a failed assertion fails the check. Teams use this to confirm firewall rules and security groups are still applied.

### How are TCP monitors priced?
TCP monitors are uptime monitors. Every plan includes a number of them: 10 on Hobby, 50 on Starter, 75 on Team, custom on Enterprise, with more available in blocks of 25. They are billed per monitor, not per run, so a 30-second schedule costs the same as a daily one. See the pricing page for current figures.

## Related

- [TCP Monitoring (full page)](https://www.checklyhq.com/product/tcp-monitoring/)
- [TCP monitors docs](https://www.checklyhq.com/docs/detect/uptime-monitoring/tcp-monitors/overview/)
- [TcpMonitor construct reference](https://www.checklyhq.com/docs/constructs/tcp-monitor/)
- [Uptime Monitoring](https://www.checklyhq.com/product/uptime-monitoring/)
- [Private Locations](https://www.checklyhq.com/product/private-locations/)
- [Status Pages](https://www.checklyhq.com/product/status-pages/)
- [Pricing](https://www.checklyhq.com/pricing/)
- [Start for free](https://app.checklyhq.com/signup/)