Skip to content

Health and Status

Report faults, events, and messages to the cloud.

  • Direction: Uplink (robot → cloud)
  • Topic: a sub-key of robot/** on the local Zenoh session (e.g. robot/fault)
  • Encoding: Cap'n Proto over Zenoh

High-level operational status travels with status telemetry. Use the message types below for discrete faults, named events, and operator-facing messages. The agent forwards these to the cloud.

Message types

Type Purpose
Fault A raise/clear condition on the robot.
Event A discrete, named occurrence the cloud can act on.
Message A human-readable note for the operator UI.
Status telemetry Continuous high-level health/mode (see Telemetry).

Fault

A fault carries a fault code, a severity, a human-readable message, the time it occurred, and whether it is currently active or has cleared.

Clear your faults. Robot software must re-send the fault with active = false when the condition clears, otherwise it persists on Rover Nexus.

See Uplink Messages → fault for the full schema, including the Severity levels.

Event

A named, robot-defined occurrence: event, a Severity, and free-text detail. Unlike a fault, an event is a point in time with nothing to clear.

The event name must be declared in the robot's capabilities manifest (events), which today means publishing a runtime capabilities manifest: robot.toml has no key for event names. An event whose name is not declared is dropped by the server.

See Uplink Messages → event.

Robot messages

Free-text notes for the operator UI, carrying a Severity. A message can optionally require operator confirmation; the reply arrives back at the robot as a messageConfirmation command. See Uplink Messages → message.

Host system health

Host CPU, memory, disk, temperature, and signal metrics are collected and reported by the agent itself, over its control-plane link to the cloud. They are not part of the robot-software uplink contract, so there is nothing for you to publish and no way to override the agent's values. See Health Monitoring.

If you want a host metric the agent does not collect (for example a secondary compute module's temperature), report it as a sensorTelemetry reading and declare it as a sensor in your capabilities manifest.

Publishing

Tip. Use faults for conditions that are raised and later cleared, events for discrete named occurrences the cloud should react to, and messages for informational notes to a human. Keep messages concise and readable.