Monitoring¶
RG provides observability at every layer of the platform: per-device, per-node, per-cluster, and per-organization. Connectivity is self-healing — agents reconnect with backoff and clusters reclaim stale endpoints — so transient failures resolve without intervention. Routine telemetry is deliberately kept separate from the audit trail, so operational monitoring never dilutes the security record.
Per-device signals¶
For each device, the platform tracks the signals that describe its operational health: liveness (whether its channel is currently up), configuration version (which settings it is running), channel state (the status of its reverse tunnel), firmware (installed version and update status), and its reported telemetry. Because these come from the device shadow, they read the same way across every vendor and model, so an operator assesses a mixed fleet with one mental model. Liveness and channel state together distinguish a device that is offline from one that is online but drifting, and configuration version against intended settings shows drift directly — the per-device layer answers "is this specific device where it should be?"
Per-node and per-cluster signals¶
Above individual devices, monitoring aggregates upward. Each node reports its capacity, the count of connected devices it currently carries, and its provisioning state, so operators can see load distribution and spot a node filling up or draining. Each cluster reports aggregate health, pending operations, and queue depths, which reveal whether the cluster is keeping pace with the work queued against it — a growing queue depth is an early signal of pressure before it becomes a failure. These layers turn thousands of device signals into a small number of health indicators an operator can watch, while still allowing a drill-down to any single device when a rollup shows a problem.
Per-organization rollups¶
At the top, the organization layer rolls signals up across every cluster into one cross-cluster inventory and its aggregate health. This is where an operator running a mix of cloud, on-premises, and air-gapped clusters sees a single fleet rather than several disconnected ones: total devices, distribution across clusters and regions, and organization-wide health. The rollup respects tenant isolation — an organization sees only its own resources — and gives leadership and central IT the one-inventory view they need to reason about the whole estate without logging into each cluster individually.
Self-healing connectivity¶
Monitoring is paired with automatic recovery, so many faults never require an operator at all. When a device loses its link, its agent reconnects with backoff, retrying on an increasing interval until the channel is re-established — appropriate for the cellular and intermittent networks devices live on. On the other side, the cluster reclaims stale endpoints left behind by a dropped channel, so allocations don't leak and the cluster's view of what is live stays accurate. Together these make transient connectivity failures self-correcting: a device that drops off reappears on its own, and the monitoring layers reflect the recovery without manual cleanup.
Telemetry kept separate from audit¶
Routine, high-frequency telemetry — heartbeats, liveness, reported metrics — is stored separately from the audit trail, and this separation is intentional. The audit trail is an investigation-grade record of consequential actions, and flooding it with continuous telemetry would bury the events that matter and inflate retention with noise. Keeping telemetry in its own monitoring path means operators get rich, frequent operational data without compromising the audit trail's signal-to-noise or its role as the authoritative record of who did what. The two systems answer different questions — "how is the fleet doing right now?" versus "what consequential actions occurred?" — and are kept apart so each does its job well.