Private-definition checks#

An ordinary check’s URL, match rule, headers, and other details live on the server, which is what lets the server show them to you, run Test on demand, and hand them to any monitor you assign. Sometimes that’s the wrong trade — the target is an internal admin URL with credentials baked in, say, and you don’t want that sitting on a server at all, even one you trust.

A private-definition check flips this: the server keeps only the check’s name, guid, and schedule. Everything else — the URL, match rule, headers, timeout, and max response time — lives only on the monitor(s) you choose, and you manage it from the command line rather than the check form.

Marking a check private#

There are two starting points, on the check form’s Definition section:

A brand-new check — tick Private definition before saving. Nothing about the definition is ever sent to the server in the first place; you fill in the real details afterwards, directly on the monitor.
An existing ordinary check — tick the same box and save. This permanently wipes the URL, match rule, headers, timeout and max response time from the server. There’s no undo. If you want a copy of the current definition first, export the check before you save.

Either way, once a check is private-definition, the check form no longer lets you edit those fields — it shows the guid you need for the next step instead.

Getting the definition onto a monitor#

Export the check to get its guid and current shape as a JSON file — either the Export link on that check’s row, or Export on the Checks page for all of them at once.
Edit the JSON file to fill in the fields the server doesn’t hold: url, match_string/match_mode, headers, timeout_sec, and so on. The guid must stay as exported — it’s how the monitor ties the definition back to the right check.
Load it into the monitor’s own local database:
```
./monitor -import-private-check my-check.json -db /path/to/monitor.db
```
This only touches the local database — no server contact, no enrollment needed for this step. Re-running it with an updated file updates the definition; the monitor doesn’t need the daemon running.

From then on, the monitor runs the check using the definition it holds locally, and reports results the same as any other check. A private check’s own error text and response detail default to being stripped before it ever leaves the monitor, since even that could reveal the URL you’re trying to keep off the server — adjustable per-check via Result detail limit if you want more.

Trying it before committing#

-test-check runs a check definition once and prints what happened, without persisting anything or needing a database, enrollment, or server:

./monitor -test-check my-check.json

Read from stdin instead with -test-check -. It exits 0 on pass, 1 on fail, 2 if it couldn’t run at all — handy for scripting. It uses the exact same checker and egress policy the daemon does, so a pass here is a real pass in production.

Reading back what a monitor holds#

Two read-only flags print the local mirror as JSON, in the same shape -import-private-check reads:

./monitor -list-checks -db /path/to/monitor.db              # everything mirrored
./monitor -export-private-checks -db /path/to/monitor.db    # only checks this agent defines

Useful as a backup before wiping a monitor’s database, or to confirm a definition actually landed the way you intended.