1. Uptime Monitoring
  2. Create a TCP monitor

Uptime Monitoring

Create a TCP monitor

TCP monitors check that OnlineOrNot can connect to a host and port from your selected monitoring regions.

Use TCP monitors for:

  • Checking databases, caches, message queues, SSH bastions, SMTP servers, and other TCP services.
  • Verifying that a port accepts connections from outside your network.
  • Sending a protocol payload and checking the response.
  • Monitoring IPv4 and IPv6 connectivity separately.

Create the monitor

Go to the checks dashboard, click Add check, then choose Monitor TCP.

Enter:

  • Check name: a name for this TCP monitor.
  • Expected outcome: whether the connection should succeed or fail.
  • IP family: IPv4 or IPv6.
  • Hostname: the hostname to connect to, for example redis.example.com.
  • Port: the TCP port to connect to, for example 6379 or 443.
  • Payload: optional data to send after the connection opens.
  • Test frequency: how often OnlineOrNot should run the TCP check.
  • Regions: where OnlineOrNot should run the TCP check from.

Click Save. The monitor starts in a pending state until OnlineOrNot runs the first TCP check.

Payloads

Leave Payload blank for a connection-only check.

If you enter a payload, OnlineOrNot sends it after opening the TCP connection. Use escaped line endings when your protocol expects them, for example:

PING\r\n

Assertions

Assertions let you fail the TCP monitor when the connection succeeds but the response is too slow or wrong.

TCP assertion types:

  • Response data: checks the response text returned by the TCP service.
  • Response time: checks how long the TCP check took in milliseconds.

For response data assertions, use comparisons such as Contains, Does not contain, Equals, or Not empty.

For response time assertions, use numeric comparisons such as Less than or Greater than. For example, add a response-time assertion with Less than and 500 to fail the monitor when the check takes 500ms or longer.

Expected failures

Set Expected outcome to Connection should fail when you intentionally want a host and port to reject connections.

Use this for cases like verifying that a private service is not reachable from the public internet.

Results

TCP result rows show:

  • Pass/fail state.
  • Checked region.
  • Target host and port.
  • Response time.
  • Retry/final-attempt metadata where applicable.

Open a result detail page to inspect the target, connection status, stored response, response time, and assertion failures.

Limitations

TCP monitors do not perform TLS certificate validation. Use an uptime check when you need to verify HTTPS behavior or SSL certificates.