Health Checks
Use Fabric.check() to check the health of a runtime server, an agent runtime, or an OpenClaw Gateway service. NVIDIA NeMo Fabric returns an immutable CheckReport with the selected target, outcome, individual observations, timestamps, and elapsed time. The Python SDK guide shows runtime and service examples.
Choose the Scope
The scope selects the component that must answer the check:
Server checks do not take a health level. Runtime and service checks default to live. The sandbox command bridge supports server and runtime targets; service checks require the local SDK service handle.
To select a runtime through the command bridge, provide both the agent name and runtime ID:
Refer to the runtime server command guide for command syntax.
Read the Levels and Outcomes
The levels describe progressively stronger observations of the selected target:
Checks are cumulative: ready evaluates live, then active, then ready. Evaluation stops at the first result that does not pass. The report’s checks list shows which observations ran. Different adapters use different native evidence; the same level does not promise identical behavior across harnesses.
The report uses one of these outcomes:
Runtime activity is separate from health. A runtime can report busy and pass every supported level while an invocation waits for a model response. Activity describes NeMo Fabric invocations; activity does not establish that an agent will accept a second concurrent prompt.
Native Evidence by Adapter
The table covers all runtime adapters and the OpenClaw Gateway service. Each row lists native evidence and unsupported levels, with links to qualification tests or capability descriptors. Support depends on the installed adapter version and its descriptor. Check the installed adapter’s advertised health levels before selecting a level.
mini-SWE-agent, NOOA InteractiveAgent, NOOA BenchAgent, and Remote Agent advertise no runtime health levels. A health check for a running runtime using one of these adapters returns unsupported/unsupported_adapter. This outcome describes check support rather than an agent failure. Server checks remain available in OpenShell environments.
Pi readiness checks configured model, tool, and MCP state. Those observations do not perform a model request or execute a tool. OpenClaw readiness follows the Gateway’s channel policies and can use the Gateway’s cached observations. The linked OpenClaw endpoint tests use controlled Gateway HTTP responses.
Passing a health check does not establish successful inference, valid model credentials, provider availability, or successful tool execution unless the particular probe verifies that property. For example, Claude’s readiness response does not require connected MCP servers, and Qwen’s command response does not test model access. The linked qualification tests hold a local model response to verify that health checks can complete during invocation; those tests provide separate invocation evidence rather than changing what the health result means.
Deadlines and Concurrent Invocations
One positive, finite timeout covers routing, worker queues, transport, all evaluated levels, and response decoding. The default is three seconds. A deadline is not restarted for each level. An expired check returns unknown/probe_timeout; the health timeout leaves the invocation running.
Some native SDK requests cannot be cancelled safely. A caller timeout can therefore leave a native health request pending. Adapters with this behavior bound their pending native work. A later check either waits within its own remaining deadline before obtaining a fresh response, or returns unknown/probe_timeout while the earlier request remains pending. A delayed response is not reused as fresh evidence for a later check.
Checks observe the selected native runtime through a health connection that is independent of the invocation request. A successful health response while an invocation is pending does not prove that the invocation will eventually succeed. Stop, release, and session replacement invalidate observations collected for an earlier owner.
Maintain the Evidence Table
When an adapter changes its advertised levels or native probe, update this table, the adapter guide, and its qualification tests together. Keep native response details in the adapter documentation and preserve the shared report schema across harnesses.