> ## Documentation Index
> Fetch the complete documentation index at: https://checklyhq.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# TCP Monitor Configuration

> Configure your TCP monitor to ensure TCP services are reachable and responding as expected.

<Tip>
  To configure a TCP monitor using code, learn more about the [TCP Monitor Construct](/constructs/tcp-monitor).
</Tip>

### Basic Setup

Configure your TCP monitor by specifying the target service:

<Frame>
  <img src="https://mintcdn.com/checkly-422f444a/9iwkS8Mlm4KfOHnA/images/tcp-request.png?fit=max&auto=format&n=9iwkS8Mlm4KfOHnA&q=85&s=1fcf5aa0d20ab1e3363e6617c7d7775e" alt="TCP monitor setup interface showing hostname, port, and protocol selection" width="1572" height="918" data-path="images/tcp-request.png" />
</Frame>

* **Hostname and port:** The server you want to monitor (e.g. `tcpbin.com` or `192.168.1.1`) and a port (e.g. 4242)
* **IP family:** Choose between IPv4 (default) or IPv6
* **This request should fail**: Enable this option to treat connection failures (e.g. timeouts or refused ports) as passed. Please note that successful connections will continue to pass. Only failed assertions will cause the check to fail
* **Data to send**: The content included in the TCP request. For example, this could be text or protocol-specific commands expected by the target service

### Assertions

Use assertions to validate TCP connection timing and response data returned by the service.

<Frame>
  <img src="https://mintcdn.com/checkly-422f444a/SdrQKfCB6NPoo3Ex/images/tcp-assertion.png?fit=max&auto=format&n=SdrQKfCB6NPoo3Ex&q=85&s=f1e4247681dc179f25bd4687d2ea10c2" alt="TCP monitor connection options showing timeout settings and data fields" width="1564" height="416" data-path="images/tcp-assertion.png" />
</Frame>

* **Response time**: Assert that the TCP connection completes within a specified time threshold
* **Response data**: Validate the data returned by the server after sending a payload. For example, when sending `USER anonymous\r\n`, you can assert that the response contains `331 Please specify the password`

For more details, see our documentation on [Assertions](/detect/assertions).

### Response Time Limits

Set performance thresholds to ensure your application meets speed requirements:

<Frame>
  <img src="https://mintcdn.com/checkly-422f444a/9iwkS8Mlm4KfOHnA/images/tcp-response.png?fit=max&auto=format&n=9iwkS8Mlm4KfOHnA&q=85&s=9eb408631ec4975963dfefe0d6317a28" alt="TCP monitor assertions interface showing response validation options" width="2448" height="444" data-path="images/tcp-response.png" />
</Frame>

* **Degraded After**: Time threshold (in milliseconds) after which the check is marked as degraded but not failed. Use for performance warnings without triggering failure alerts
* **Failed After**: Time threshold after which the check fails completely. Use for hard performance limits where slow responses should trigger alerts

### Frequency

Set how often the monitor runs (every 10 seconds to 24 hours):

<Frame>
  <img src="https://mintcdn.com/checkly-422f444a/9iwkS8Mlm4KfOHnA/images/tcp-frequency.png?fit=max&auto=format&n=9iwkS8Mlm4KfOHnA&q=85&s=f550473b30dee82fa881431c28f11acf" alt="TCP monitor frequency selection interface" width="1572" height="358" data-path="images/tcp-frequency.png" />
</Frame>

### Scheduling & Locations

<Frame>
  <img src="https://mintcdn.com/checkly-422f444a/9iwkS8Mlm4KfOHnA/images/tcp-scheduling-strategy.png?fit=max&auto=format&n=9iwkS8Mlm4KfOHnA&q=85&s=9a3b569dc2183f7b24dd8bf0d9f0f6fc" alt="TCP monitor scheduling strategy and location selection interface" width="1566" height="1368" data-path="images/tcp-scheduling-strategy.png" />
</Frame>

* **Strategy:** Choose between round-robin or parallel execution. Learn more about [scheduling strategies](/concepts/scheduling)
* **Locations:** Select [public](/concepts/locations/#public-locations) or [private](/platform/private-locations/overview) locations to run the monitor from

### Additional Settings

* **Name:** Give your monitor a clear name to identify it in dashboards and alerts
* **Description:** Add context about what this monitor does and why it matters. Supports markdown, max 500 characters. When a failure occurs, [Rocky AI](/ai/rocky-ai) uses the description to provide more accurate [root cause and user impact analysis](/resolve/ai-root-cause-analysis/overview)
* **Tags:** Use tags to organize monitors across dashboards and [maintenance windows](/communicate/maintenance-windows/overview)
* **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
* **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations

<Note>
  TCP monitors provide network-level connectivity verification. For application-level monitoring, consider adding [synthetic monitoring](/detect/synthetic-monitoring/overview) to your monitoring strategy.
</Note>