Security

You can run checks from our locations without installing anything. The private agent exists only for things that are not reachable from the internet — a database on a private network, an internal API, a service behind a firewall. This page says exactly what the agent does, in plain language.

What the agent does

The agent dials out to us over HTTPS (TLS 1.2+) and makes a small, fixed set of requests: enrol once, send a heartbeat, fetch its list of checks, submit results — plus page-speed results if you turn page-speed on for one of its checks. Nothing else. It opens no inbound ports, and we never connect to it. If your firewall only allows outbound port 443, the agent works.

What it never does

The agent never receives commands from us. A check tells it what to look at, not what to run. The only external programs it starts are ping, mtr and traceroute, with fixed arguments, and never through a shell.

What it sends back

For each check, the agent reports status, response time and error message. For HTTP checks, it also reports response headers and timings, and the first 500 characters of the response body; on a failure it attaches up to 50 KB of the response so you can see what was served. For content monitoring, it sends a fingerprint (hash) of the page text rather than the text itself, plus up to 2 KB of the changed fragment when it detects a change.

Credentials — read this before pointing it at anything sensitive

A private agent also receives the rest of what its checks need, exactly as you stored it: HTTP headers or a request body you configured (which may hold an Authorization header or an API key) and an FTP username are sent as-is. A database password is the one field we keep encrypted at rest — it is decrypted when the check is dispatched and sent to that agent over the same HTTPS connection. Geo agents receive none of this. If you would rather not hand a machine those credentials, monitor the endpoint in front of the resource instead.

Whatever a credential is, it is stored on the host only in the agent's config file, mode 0600, owned by the agent's own system user.

How it runs on your host

The agent runs as a dedicated system user with no login shell, with NoNewPrivileges, ProtectSystem=strict and ProtectHome=true set. It ships no setuid binaries and does not use cap_net_raw — ICMP works through a sysctl instead. The enrolment key is shown to you once and stored hashed (SHA-256) on our side.

Other addresses it contacts

The agent contacts api.ipify.org to learn its own public IP for the heartbeat, and www.google.com/generate_204, one.one.one.one and www.cloudflare.com/cdn-cgi/trace as a self-check, so a broken uplink is not reported as your service being down. Crash reporting is off unless you set a DSN.

Where your data lives

Servers are located in the European Union (OVH, France). Check logs are retained according to your organization's plan (Free plan: 7 days; higher on paid plans), up to a 90-day platform maximum. The database is backed up daily and the last 7 backups are kept.

Removing it / deleting data

To remove the agent from a host, run systemctl disable --now healthcheck-agent and delete /etc/healthcheck-agent and /opt/healthcheck-agent, then delete the agent in the UI.

To remove your account and data entirely, see Delete your account. See also our Privacy Policy, Terms of Service, and the private agent docs.