TCP, UDP, and database checks work by connecting directly to host:port from ObserveOne's cloud, in whichever region you assign the check to. That is different from an HTTP check hitting a public URL: a database, cache, or internal service is often deliberately kept off the public internet, and pointing one of these checks at it means making it reachable from outside your network.

We do not block this. Reaching an address is your call, including a private or self-hosted target. But exposing a database to the internet is a real risk, so treat it deliberately rather than as a side effect of adding a monitor.

What "reachable" means here#

These checks run from ObserveOne's own infrastructure, not from inside your network and not from a browser. If ObserveOne cannot open a connection to host:port from the public internet, the check cannot succeed. There is no installable, in-network collector today, so for now that means the target itself must accept inbound connections from outside your network.

Reduce the exposure#

If you do expose a database or internal service so ObserveOne can check it, narrow what that exposure can do:

Least-privilege monitoring user. Create a dedicated database user for the check, separate from application accounts. Grant it only what a liveness or connectivity check needs, typically CONNECT and nothing else, no read access to tables, no write access at all.
Require TLS. Enable TLS on the database or service and configure the check to use it, so the connection (and any banner or credential exchange) isn't sent in the clear.
Scope by network where you can. If your database or cloud provider supports connection-level restrictions (a firewall rule, a security group, a proxy in front of the database), restrict inbound connections to the narrowest range you can, rather than opening the port to 0.0.0.0/0.
IP allowlisting. ObserveOne does not currently publish a fixed set of egress IP addresses, so allowlisting by ObserveOne's IPs is not something we support today. Don't rely on IP-based restriction as your only control; use the least-privilege user and TLS above as the actual safeguard.

Prefer not to expose it at all#

The guidance above reduces the blast radius, but the underlying tradeoff (a database reachable from the public internet) doesn't go away. If exposing the target isn't acceptable for your environment, don't add a TCP, UDP, or database check against it until an in-network option exists. An HTTP check against a public endpoint, or a heartbeat check where your service reports in instead of being reached, avoid the exposure question entirely.