Skip to content

Passive checks

Not everything worth monitoring can be polled — an SNMP trap, a batch job that only knows its own outcome, an external system pushing results in. Passive checks are jaque’s side of that contract: an object whose state comes from the outside, not from jaque running a probe.

services: backup: check: {
type: "passive"
freshness_threshold: "24h"
stale_status: "CRITICAL"
}

freshness_threshold is required, with no default — deliberately. An unbounded freshness window is exactly the silent-green failure mode this check type exists to prevent: if nobody ever posts a result again, jaque has to have an opinion about that, and the schema forces you to state one.

Once a result is older than freshness_threshold, the object is forced to stale_statusUNKNOWN by default, or WARNING/CRITICAL if you set it. stale_status intentionally cannot be OK: staleness means “jaque doesn’t actually know”, never “everything’s fine.” The rest of #Schedule still applies underneath — max_attempts and retry_interval govern the soft-to-hard ladder a stale object walks, check_interval is how often staleness gets re-evaluated once hard, and flap behaves the same as anywhere else. timeout is the one field with no meaning for a passive check.

Two doors, same destination — see FIFO and API for the full detail:

  • The Nagios-compatible FIFOPROCESS_SERVICE_CHECK_RESULT / PROCESS_HOST_CHECK_RESULT lines, for anything that already speaks the legacy wire format.
  • The ConnectRPC API’s ProcessCheckResult / ProcessCheckResults (batch) RPCs — the better fit for a translator receiving bursts, since the batch call validates all-or-nothing and enqueues in order.

Both land on the same command channel the engine consumes, tagged origin: passive, and a result for an object that isn’t declared passive is discarded with a warning rather than silently accepted.

See SNMP traps for the reference pipeline that turns trap floods into passive results without forking a process per trap.