Skip to main content
Learn more about all the TCP monitor capabilities in the general overview.
This guide walks you through creating your first TCP monitor to check the availability of your network services, databases, or any TCP-based application. TCP monitors verify the availability of non-HTTP services by establishing a connection to a specific host and port.

​
Basic Setup

Configure your TCP monitor by specifying the target service:
TCP monitor setup interface showing hostname, port, and protocol selection
  • Hostname: The server you want to monitor (e.g. db.example.com)
  • Port: The TCP port your service is listening on (e.g. 3306 for MySQL)
  • IP family: Defaults to IPv4
  • Data to send: Optional data to transmit after establishing connection
  • This request should fail: Treat connection failures (e.g. timeouts or refused ports) as passed. Failed assertions still fail the check

​
Assertions

Add assertions on the response time or response data of your TCP request:
TCP monitor assertions table with response time and response data sources

​
Response Validation

Validate the service response for more precise monitoring:
TCP monitor assertions interface showing response validation options
  • Response data: Expected text pattern in the response
  • Response time limits: Define performance thresholds for degraded or failed states

​
Frequency

Set how often the monitor runs (every 10 seconds to 24 hours):
TCP monitor frequency selection interface

​
Scheduling & Locations

TCP monitor scheduling strategy and location selection interface
  • Strategy: Choose between round-robin or parallel execution. Learn more about scheduling strategies
  • Locations: Select public or private locations to run the monitor from

​
Additional Settings

  • Name: Give your monitor a clear name to identify it in dashboards and alerts
  • Tags: Use tags to organize monitors across dashboards and maintenance windows
  • Description: A description of the check. Supports Markdown. Maximum length: 500 characters
  • Retries: Define how failed runs should be retried. See retry strategies
  • Alerting: Configure your alert settings, alert channels, or set up webhooks for custom integrations
TCP monitors provide network-level connectivity verification. For application-level monitoring, consider adding synthetic monitoring to your monitoring strategy.