Private Networks

What Zharp can monitor when it can't reach your systems from the internet, what it can't do yet, and the addresses it refuses to check.

Most monitors — websites, APIs, ping, ports, certificates — are checked from Zharp's own servers, so the target has to be reachable from the internet. For anything that isn't, the data has to come out from the inside instead: from the Zharp agent, from your app, or from the job itself. All of these only make outbound HTTPS requests to api.zharp.io; nothing in your network has to accept a connection.

What works today

Databases through the agent

Install the agent on a server that can reach the database — usually the database's own server — and give it a monitoring user. The database then appears in Agent connection when you create a private database monitor. The full steps, and exactly when such a monitor goes down, are in Private Databases.

The agent doesn't have to share a machine with the database. Point it at any address it can reach — this is how one agent on a jump host or bastion can watch a database with no agent of its own:

# the agent on a jump host, watching a database elsewhere on the private network
sudo zharp-collector add postgres --host 10.0.0.12 --password 'choose-a-password'
sudo zharp-collector add redis --endpoint 10.0.0.30:6379 --password '<redis password>'

One agent can report on several databases of the same engine: add each one after the first with --name, for example zharp-collector add postgres --name orders --host 10.0.0.12 .... See Private Databases.

Logs, traces and cron jobs

• Logs: the agent tails nginx, Apache, IIS and system logs by itself; add your own files with zharp-collector add logs --service NAME --path PATH. Then create a log monitor on that service. See Logs.
• Traces: the agent accepts OpenTelemetry on localhost only and forwards it, so services that can't reach the internet can still send traces through it. See Through the Agent.
• Cron jobs: a heartbeat is an outbound request from the job, so a job on a private server only needs to reach api.zharp.io over HTTPS. See Cron Jobs & Heartbeats.

What the agent can't do yet

The agent collects and forwards; it doesn't run checks. Website, API endpoint, keyword, ping, port, SSL certificate, DNS, mail (SMTP, IMAP, POP3) and user journey monitors always run from Zharp's servers, over the internet. There is no way today to run an HTTP request, a ping or a port check from inside your network.

Until there are agent-run checks, a common workaround for an internal HTTP service is a small scheduled job on a machine inside the network that calls the service and, only if it answers, pings a cron job monitor:

*/5 * * * * curl -fsS --max-time 10 http://10.0.0.5:8080/health > /dev/null && curl -fsS --retry 3 https://api.zharp.io/api/v1/ping/YOUR_TOKEN > /dev/null

Addresses Zharp won't check

Every check that runs on Zharp's servers refuses targets inside a network rather than on the internet:

IPv4 addresses written another way are judged by the address they stand for: IPv4-mapped IPv6 such as ::ffff:169.254.169.254, NAT64 and 6to4 forms, and decimal or hex spellings such as http://2130706433/.

Why

A check runs on Zharp's servers, so these addresses would point into Zharp's own network, not yours. 169.254.169.254 in particular is the cloud metadata service, which hands out credentials to anything that can reach it.

When it's checked

• On save. Creating or editing a monitor fails when its URL, host, custom DNS resolver or proxy is one of these addresses, or a host name that resolves to one — for example intranet.example.com resolves to 10.20.30.40, which is a private network address and cannot be checked from Zharp's servers.
• On every check. The address actually dialled is checked again, so a name that is pointed inward after it was saved (DNS rebinding) fails the check with the same message. This also covers each redirect an HTTP check follows, every request a workflow step makes, every page and resource a user journey loads, links the broken link checker follows, and webhook notifications to your own URLs.

Private database monitors are the exception: their address is only what the agent reports — often localhost, because the agent sits on the database's server — and Zharp never connects to it. Log, application, cron and IP blacklist monitors don't connect to their target either, so they aren't affected.