Fleet monitoring
Once an agent is enrolled, it reports basic host telemetry back to Sencai. This page covers where to see it and how to read it. For patch and software data specifically, see Patch management and Software inventory.
Connectivity vs. telemetry
Section titled “Connectivity vs. telemetry”Two related but different things show up in the app:
- Connection status - shown on Fleet → Agents (
/gravity/agents): whether an agent is currently connected, and when it last sent a heartbeat. This comes from the agent’s own heartbeat, sent every 30 seconds, and is what tells you a host is reachable at all. - Host telemetry - shown on Fleet → Agent Telemetry (
/gravity/fleet/telemetry): CPU, memory, and disk usage per agent, refreshed every 60 seconds.
A host can show as connected on the Agents page while its telemetry table is empty or stale - the two are collected on separate cycles, and telemetry collection is a platform-side setting for your environment rather than something you turn on per agent.
What the telemetry table shows
Section titled “What the telemetry table shows”| Column | Meaning |
|---|---|
| Agent ID / Agent Name | Which host the row is for |
| CPU % | CPU utilization at the time of the snapshot |
| Mem | Memory used, shown in MB or GB |
| Disk % | Disk utilization at the time of the snapshot |
| Last Seen | When this snapshot was recorded |
CPU above 80% and disk above 90% are highlighted so a host under real pressure stands out without you having to scan every row.
The table refreshes automatically every 60 seconds while you have it open, and you can force an immediate refresh with the Refresh button.
Stale heartbeats
Section titled “Stale heartbeats”On Fleet → Agents, a host marked active is treated as stale - and flagged visually - if its last heartbeat is more than about 90 seconds old. In practice this usually means one of:
- A brief network blip - the agent’s own reconnect logic (with backoff) generally recovers within a minute or two without you doing anything
- The host is under enough load that the agent process itself is struggling to run its own heartbeat loop on schedule
- The agent process has stopped or the host has gone down entirely
If a host stays stale for more than a few minutes, it’s worth checking directly (SSH, or the browser terminal if it’s a registered cloud instance) rather than assuming it will recover on its own.
Acting on what you see
Section titled “Acting on what you see”Telemetry here is read-only - it tells you a host is under pressure, but doesn’t do
anything about it by itself. If a host is consistently showing high disk usage, for
example, you can dispatch a cleanup action against it directly from
Remote execution (the built-in clear_disk_space runbook
action covers exactly this case) rather than SSHing in by hand.
Reading it during an incident
Section titled “Reading it during an incident”Telemetry here is a snapshot, not a live stream - treat a single reading as a point in time, not a trend. If you need a history of a metric over time, or threshold-based alerting so you don’t have to watch this table yourself, see Monitoring under Operations, which covers platform-wide alerting and incidents.
What’s next
Section titled “What’s next”- Fleet agent - what else the agent collects and how often
- Patch management - patch scan results per agent
- Operations → Monitoring - alerting and incident response
- Remote execution - acting on what you see here