Skip to content
OpenStatus openstatus

TCP Monitor Reference

Overview

Section titled “Overview”

A TCP Monitor is a component that establishes a connection to a specified TCP endpoint (IP address and port) to verify its reachability and responsiveness. This is fundamental for monitoring the availability of services that communicate over TCP, such as databases, mail servers, and custom network services.

Use cases:

  • Database server availability checks (e.g., PostgreSQL, MySQL).
  • Mail server (SMTP, IMAP, POP3) reachability.
  • Custom application service port monitoring.
  • Validating network connectivity to specific endpoints.

Configuration

Section titled “Configuration”

URI

Section titled “URI”

Type: String (required) Format: Hostname or IP address with port (e.g., example.com:8080, 192.168.1.1:22)

The endpoint of the TCP service you want to monitor. This includes the hostname or IP address and the port number.

Examples:

  • openstat.us:443
  • db.internal:5432
  • 10.0.0.5:3306

Regions

Section titled “Regions”

Type: Array of Strings (required) Format: Region identifiers (e.g., iad, jnb)

The geographical regions from which the TCP connection attempt will be initiated. This allows for verification of service availability and network latency across different global locations.

Africa

  • Johannesburg, South Africa 🇿🇦 (free)

Asia

  • Hong Kong, Hong Kong 🇭🇰 (free)
  • Mumbai, India 🇮🇳
  • Singapore, Singapore 🇸🇬
  • Tokyo, Japan 🇯🇵

Europe

  • Amsterdam, Netherlands 🇳🇱 (free)
  • Bucharest, Romania 🇷🇴
  • Frankfurt, Germany 🇩🇪
  • London, United Kingdom 🇬🇧
  • Madrid, Spain 🇪🇸
  • Paris, France 🇫🇷
  • Stockholm, Sweden 🇸🇪
  • Warsaw, Poland 🇵🇱

North America

  • Ashburn, Virginia, USA 🇺🇸 (free)
  • Atlanta, Georgia, USA 🇺🇸
  • Boston, Massachusetts, USA 🇺🇸
  • Chicago, Illinois, USA 🇺🇸
  • Dallas, Texas, USA 🇺🇸
  • Denver, Colorado, USA 🇺🇸
  • Guadalajara, Mexico 🇲🇽
  • Los Angeles, California, USA 🇺🇸
  • Miami, Florida, USA 🇺🇸
  • Montreal, Canada 🇨🇦
  • Phoenix, Arizona, USA 🇺🇸
  • Queretaro, Mexico 🇲🇽
  • Seattle, Washington, USA 🇺🇸
  • San Jose, California, USA 🇺🇸
  • Toronto, Canada 🇨🇦

South America

  • Bogota, Colombia 🇨🇴
  • Buenos Aires, Argentina 🇦🇷
  • Rio de Janeiro, Brazil 🇧🇷
  • Sao Paulo, Brazil 🇧🇷 (free)
  • Santiago, Chile 🇨🇱

Oceania

  • Sydney, Australia 🇦🇺 (free)

Frequency

Section titled “Frequency”

Type: String (required) Format: Duration string (e.g., 30s, 1m, 1h)

The interval at which the TCP monitor will attempt to connect to the target URI. Supported frequencies:

  • 30 seconds
  • 1 minute
  • 5 minutes
  • 10 minutes
  • 30 minutes
  • 1 hour

Response Time Thresholds

Section titled “Response Time Thresholds”

Timeout

Section titled “Timeout”

Type: Duration (optional) Default: 45 seconds

The maximum duration to wait for a successful TCP connection. If the connection cannot be established within this time, the check is considered a failure.

Degraded

Section titled “Degraded”

Type: Duration (optional)

The duration after which a TCP connection attempt is considered to be in a degraded performance state. This allows for early warning of network latency or service slowdowns.

Retry

Section titled “Retry”

Type: Integer (optional) Default: 3

The number of times the monitor will automatically retry a failed TCP connection attempt before reporting a definitive error. For example: 3

OpenTelemetry

Section titled “OpenTelemetry”

Configures the export of monitoring metrics to an OpenTelemetry-compatible observability platform.

OTLP Endpoint

Section titled “OTLP Endpoint”

Type: String (optional) Protocol: HTTP only

The OTLP (OpenTelemetry Protocol) endpoint URL where collected metrics should be exported. Only HTTP endpoints are supported for metric export.

OTLP Headers

Section titled “OTLP Headers”

Type: Key-value pairs (optional)

Custom headers to include when sending metrics to your OTLP endpoint. Commonly used for authentication or tenant identification.

Common example:

Authorization: Bearer <your_token>
Section titled “Related resources”