Verified plugins

ai.oz0/host-health

The health of the node an agent runs on, read-only and offline, and an on-call agent that summarises it.

For: tenant administrators and plugin users.

ai.oz0/host-health reads the node's local health. Its oz0-host-health agent answers alerts and questions with a status line, findings with numbers, and commands for the person on call to run next.

Every function is read-only and closed-world: it makes no changes and opens no network connection.

FunctionWhat it reads
oz0_host_health.diskEvery filesystem with data: size, used and free space, inodes, with a warning at warn_percent (85 by default)
oz0_host_health.memoryMemory and swap, with warnings for pressure
oz0_host_health.cpuLoad per core, how busy the CPUs are over half a second, uptime, and the five busiest processes by CPU and memory, by name only
oz0_host_health.failed_servicesFailed systemd units, from systemctl
oz0_host_health.recent_errorssince_minutes, limit, unit: journal entries at priority err or worse, counted per unit

Log messages are cut to 400 characters, and values that look like passwords, tokens, bearer credentials or AWS keys are replaced before they reach the model. Process command lines are never read.

Install

Its agent oz0-host-health asks for the tenant's default model alias with tools, never a vendor's model, so it runs on whichever provider the tenant set up first; map it elsewhere with oz0 model alias set default <provider>/<model>.

Terminal
oz0 plugin install hub:ai.oz0/host-health
oz0 run oz0-host-health "Disk almost full alert on web-3"

On a node with sandbox tier 1 the functions run only where the node's operator allows it: they read the machine, which a sandbox hides, so with the default --plugin-sandbox strict the tool does not start until that node runs oz0-node run --plugin-sandbox-exempt host-health, or oz0-node service install with the same flag. Exempt the node before the install: an install's quality gate runs the plugin's evals on a test node, and a node that holds the tool back fails them, with this reason on the gate's line.

An exemption of one PLUGIN@COMMIT does not cover the next version, so updating a pinned plugin needs its new commit first, or the plugin's name alone. Until then the plugin's status and the node's findings say so. In a job an outside event started, and in a harness session's own servers, the calls are not made, since they would read that sandbox.

The functions read the node they run on, so send the job to the host with a label. Reading the whole system's journal needs the node's user in the systemd-journal (or adm) group; without it the function says only the user's own journal was readable. The plugin runs on Linux nodes only.

On this page
Copyright © 2026