openstatus logoDashboard

TCP Monitor Reference

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

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

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

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

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

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

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

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

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

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>