--- title: "TCP check | Grafana Cloud documentation" description: "TCP check A TCP check connects to an endpoint on a given hostname or IP address and a port. This ensures a server accepts the connection and measures response latency and uptime. TCP checks operate at the transport layer and are ideal for monitoring TCP-based services such as mail servers, FTP servers, and message queues." --- > For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt). # TCP check A TCP check connects to an endpoint on a given hostname or IP address and a port. This ensures a server accepts the connection and measures response latency and uptime. TCP checks operate at the transport layer and are ideal for monitoring TCP-based services such as mail servers, FTP servers, and message queues. ## Create a TCP check You can create and execute a TCP check from the Synthetic Monitoring UI. 1. On the left-side menu, select **Testing & synthetics** > **Synthetics**. 2. Click **Create new check** or **Add new check**. 3. Choose **API Endpoint** as your check type. 4. Set the value for the required [options](#options). 5. Schedule or run the check. 1. Click **Save** to schedule the check. 2. Click **Test** to run the TCP check. ## Options The list of common options to all check types: Expand table | Option | Description | |-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Enabled | Whether the check is enabled or not. | | Job name | Refer to the check name. Check metrics include a `job` label with the value of this option. | | Target | Target of the check request. Check metrics include an `instance` label with the value of this option. | | Probe locations | The locations where the check should run from. Check metrics include a `probe` label with the value of the probe location running the check. | | Frequency | The frequency the check should run in seconds. The value can range from 10 to 3600 seconds. Only the `sm_check_info` metric includes the `frequency` label. | | Timeout | Maximum execution time for the check. The value can range from 1 to 60 seconds. | | Custom labels | (Optional) Custom labels applied to check metrics. Refer to [Custom labels](/docs/grafana-cloud/testing/synthetic-monitoring/analyze-results/custom-labels/) for querying instructions. | Additionally, TCP checks have the following options: Expand table | Option | Description | |---------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Use TLS | Whether or not TLS is used when the connection is initiated. | | Query and response | The response to expect and the data to send. | | Disable target certificate validation | Whether to validate the certificate that is presented. | | Server name | The server name used during certificate validation. | | CA certificate | The certificate for the certificate authority. | | Client certificate | The client certificate to present during authentication. | | Client key | The corresponding key for the client certificate. | | IP version | The IP version to use: `V4` (IPv4 only), `V6` (IPv6 only), or `Any` (prefers IPv6, falls back to IPv4). With `Any`, if no IPv6 (AAAA) record exists, the check uses IPv4 (A) records. The check doesn’t retry with a different IP version if the initial connection fails. | | Publish full set of metrics | Whether to publish additional metrics to create histograms (used for Apdex scores or heatmaps). Default is false to reduce the number of active series. | These last options don’t produce any [additional labels in the resulting check metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/#metric-labels). ## Metrics Checks store their results as Prometheus metrics, including the list of common metrics: Expand table | Metric | Description | |------------------------------|---------------------------------------------------------------------| | `probe_all_duration_seconds` | Returns how long the probe took to complete in seconds (histogram). | | `probe_duration_seconds` | Returns how long the probe took to complete in seconds. | | `probe_all_success` | Displays whether or not the probe was a success (summary). | | `probe_success` | Displays whether or not the probe was a success. | | `sm_check_info` | Provides information about a single check configuration. | Additionally, TCP checks produce the following metrics: Expand table | Metric | Description | |-------------------------------------------------|----------------------------------------------------------------------------------------| | `probe_dns_lookup_time_seconds` | Returns the time taken for probe DNS lookup in seconds. | | `probe_failed_due_to_regex` | Indicates if probe failed due to regular expression. | | `probe_ip_addr_hash` | Specifies the hash of the IP address. It’s useful to detect if the IP address changes. | | `probe_ip_protocol` | Specifies whether the probe IP protocol is IP4 or IP6. | | `probe_ssl_earliest_cert_expiry` | Returns last SSL chain expiry in Unix time. | | `probe_ssl_last_chain_expiry_timestamp_seconds` | Returns last SSL chain expiry in timestamp. | | `probe_ssl_last_chain_info` | Contains SSL leaf certificate information. | | `probe_tls_version_info` | Returns the TLS version used or `NaN` when unknown. |