Custom checks
A custom check is a rule the agent evaluates on its own schedule, every minute by default, and turns into check_failed and check_recovered events, which become alerts. Checks are data over a fixed catalogue of primitives, validated on the machine. The hub pushes data, never code.
The document
{
"checks": [
{
"id": "chk-drive-mapped-s",
"name": "S: mapped for reception",
"severity": "warn",
"every": "1m",
"rule": { "when": { "user_logged_in": {} },
"then": { "drive_mapped": { "letter": "S" } } }
}
]
}id is stable and unique per machine; severity is info, warn or crit; every is an interval from 1m to 24h. The hub keeps the approved document per machine and re-pushes it when a machine reconnects with an older version.
Primitives
| primitive | arguments | passes when |
|---|---|---|
| ping | host, count, max_loss_pct, max_avg_ms | loss and latency are within limits (OS ping; also sampled every heartbeat) |
| url_reachable | url, max_ms, expect_status | the URL answers in time with the expected status |
| http_check | method, url, headers, body, expect_status or class, body_contains, json_path and json_equals, max_ms, tls_min_days, insecure_tls | an application answers the way its users need |
| dns_resolves | name, expect_ip | the name resolves (to the expected address) |
| share_reachable | host, port | a TCP port on another host accepts connections |
| port_listening | port | something listens on this machine |
| service_running | name | the service is running (SCM, systemd, rc, procd) |
| process_running | name, min_count | at least that many processes match |
| path_exists | path, type | a file or folder exists |
| file_age_max | path, max_age | the file was modified recently enough |
| file_size_min | path, min_bytes | the file is at least that big |
| dir_free_gb_min | path, min_gb | the volume has enough free space |
| printer_present | name | the printer is installed (Windows) |
| drive_mapped | letter, unc | the drive letter is mapped for the logged-in user (Windows) |
| registry_value | key, name, expect | a registry value matches (Windows) |
| user_logged_in | user | someone, or that user, is logged in |
| time_window | days, from, to | now is inside the window (use with when) |
Combinators
all, any and not take lists of rules. when … then … evaluates the second rule only if the first passes, so a mapped-drive check waits for a user and a business-hours check waits for the window. A check can carry a message for the alert and a remediation note for the technician.
Application and API checks
http_check probes an application the way its users reach it: GET, HEAD or POST with headers and a JSON or text body. Credentials never go in the check. A header value of {"secret": "app_token"} is resolved on the machine from the secrets map in its local configuration, which the hub never reads. The latest result of every HTTP check rides on the heartbeat, so the machine's trends show response time and failures over time, and BE AI sees them.
Writing one
In the machine's checks tab: pick a primitive, fill its fields, add it to the list, push (two-step). A raw JSON view covers combinators and messages. Or ask BE AI in Discuss: "add a warning check when D: has less than 50 GB free". It files the check as a proposal in the correct format; you approve; the agent validates and starts evaluating it immediately.
Checks on proxied devices
Devices watched through a proxy take service, process, path, file age, free space and ping checks, evaluated by the proxy over SSH on every poll, with the same events and alerts.
Try it on one machine first.
The install line takes a minute. Uninstall the agent and you are out.