> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Fleet health
> Read the whole agent fleet at a glance — what is online, what went quiet, what is failing, and what changed.
**Fleet** is where you find out whether your agents are actually working, without opening them one
at a time. The Komodor Agentic Operation Platform (KAOP) computes presence, capacity, reliability,
and version churn from the same run records that back everything else, so the numbers here and the
numbers on a run agree. This page explains what each figure means and which questions it answers.
Find it under **Agents → Fleet**.
## The four views
| View | What it answers |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| **Overview** | How is the fleet doing over a period — volume, cost, latency, error rate, version churn — and what is its live state right now. |
| **Agents** | Which specific agent is in which state, filterable and sortable. This is where `/agents` lands. |
| **Triggers** | Which recurring schedules exist, when each last fired, and whether it is enabled. |
| **Archived** | Retired agents, reached from the **Archived (N)** toggle in the toolbar. Their history survives archiving. |
## Agent state, precisely
An agent's state is computed from presence, not declared. The control plane pings each open worker
connection; the worker's reply is the only thing that updates presence. If replies stop arriving for
**90 seconds**, the agent reads as offline.
| Status | What it means |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Online** | The worker replied inside the presence window. |
| **Offline** | It did not. The agent still exists, its history is intact, and it comes back on the next reply. |
| **Draft** | The agent has never reported in. A draft goes live automatically on its worker's first contact — there is no separate activation step. |
| **Deploying** | A first deploy is in flight. |
| **Deploy Failed** | A first deploy did not complete. |
Several qualifiers can sit beside the status, because they are independent of presence:
* **Disabled** — triggers will not fire for this agent. Manual and chat invocations still work.
* **Archiving** / **Archived** — retiring, and retired. An agent reads *Archiving* until its last
replica is genuinely gone, then *Archived*.
* **New version deploying**, **Restarting**, **Reverting** — a rollout on an agent that is already
live, so its status stays *Online* while the badge shows what is happening.
* **Deploy failed** — a rollout onto an already-live agent failed. The previous version keeps
serving.
"Offline" and "unreachable" are different facts. Offline means presence lapsed. An agent can be
heartbeat-online while its message channel is not reachable — the Overview calls that out
separately, because the fix is different.
## The Overview tab
### Choosing a period
The window selector offers **Today**, **Last 7 days**, and **Last 30 days**, and defaults to 30
days. It is calendar-day inclusive: *Today* means today so far, not a rolling 24 hours. The
selector governs this tab's period figures only.
### The four headline figures
| Card | What it reports |
| -------------------------- | ------------------------------------------------------------------------------ |
| **Outcomes & reliability** | Finished runs in the window, split into succeeded and failed. |
| **Cost** | Spend in the window, and cost per finished run. Links through to spend detail. |
| **Latency (mean)** | Mean completed-run duration. |
| **Changes** | How many new agent versions were deployed in the window. |
**Changes** is the figure most teams under-use. A reliability dip that lines up with a spike in
deployed versions is a rollout problem, not an agent problem — and that correlation is one glance
here rather than an investigation.
### Trends and leaderboards
Three charts plot the window day by day: **Runs & errors over time**, **Cost over time**, and
**Latency over time**. Splitting runs from errors on separate rows is deliberate — an outage day
stands out without hiding the throughput underneath it.
Three panels rank what needs attention:
* **Worst error rate** — agents ordered by failure rate, with the run count behind each rank so a
rate comes with its volume. A minimum-run floor applies to the denominator, so a single bad run
on a barely used agent cannot top the board. On a short window the floor can legitimately exclude
everything, and the panel says so rather than implying a healthy fleet.
* **Slowest agents** — ordered by mean duration, with no floor. A slow agent is worth seeing on its
first few runs.
* **Model mix** — which models the fleet actually used, sized by run volume and labelled with spend.
Two entries in the model mix are structural rather than models a worker reported:
| Entry | What it is |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `(other)` | Everything past the top models, folded into one row that carries the tail's runs and cost — so the slices still sum to the fleet totals. |
| `(unattributed)` | Runs whose usage record names no model at all. This is a signal about your workers' reporting, not about the fleet's model choice. |
### Live state
Three cards describe right now rather than the window, and refresh on their own.
Four exhaustive buckets — **online**, **offline \<24h**, **offline >24h**, and **draft** —
each linking into the filtered agent list. Splitting recent from long-standing offline matters:
a worker that stopped an hour ago is an incident, and one that stopped last month is a cleanup
task.
A **Just went offline (last hour)** call-out names the agents that changed state most recently,
which is almost always what you came to find.
Live **replicas**, how many are **busy** versus free, how many runs are **queued**, and the age
of the **oldest queued** run. Oldest-queued is the number to watch: a growing backlog with idle
replicas is a routing problem, and a growing backlog with no free replicas is a capacity one.
An **Online, 0 live replicas** call-out flags an agent that reads online with nothing serving —
which happens when a candidate arm keeps the agent present while its production arm is dead.
Which online agents cannot currently be reached over their channel, headed
**Heartbeat-online, channel-unreachable**, plus the **SDK version mix** across live workers.
The version mix is how you find the worker that never got upgraded.
Live figures and period figures refresh on different cadences — presence is polled every 10 seconds
and the window metrics every 60 — so a period number beside a presence row can be up to a minute
older than it.
## The Agents tab
### The list
| Column | What it shows |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Name** | The agent, with badges for how it is hosted and run. |
| **Status** | The status and its qualifiers, as above. |
| **Last run** | The most recent run's outcome and when it happened. |
| **Last change** | When the agent's definition last changed. |
| **Instances** | Live replicas, split into busy and free. When a candidate arm is live, a second line reads `N production · M shadow`. |
| **Activity (30d)** | Four figures in one cell — runs and cost on the first line, error rate and mean latency on the second. This column is pinned to 30 days regardless of the Overview's selector. |
Click any sortable header to rank by it. Because the activity cell holds four numbers, its header
offers a **Sort by** choice of **Runs**, **Cost**, **Error rate**, or **Avg latency** — so the
ranking always names what it ranked by. Error-rate sorting suppresses agents with too few runs in
the window, for the same reason the leaderboard has a floor.
An em dash in an activity cell means "not measured", which is not the same as zero. An agent created
in the last minute has no measurement yet; a route that does not request window metrics shows none
at all.
### Narrowing the fleet
* **Search** matches an agent's name, id, worker id, description, tools, and labels.
* **Status** facets: **All active agents**, **Online**, **Offline**.
* **Shadow**: **Shadow active** filters to agents currently running a candidate arm — see
[Model Evaluation](/manage-your-agents/optimize/model-evaluation).
* **Labels**: one facet group per label key your agents declare, so `team`, `env`, or `tier` become
filters without anyone configuring them.
* **Clear filters** returns you to the whole fleet. Use it when you arrive from a composition
card's link — those can select combinations the facet buttons cannot express, which leaves the
buttons reading inactive.
Search scopes the Agents tab only. The Overview deliberately ignores it, so that a query typed on
one tab cannot silently narrow numbers on another with no visible control to clear it.
## An individual agent
Opening an agent gives you the same picture for one agent, plus what only it can tell you:
* **Run history** and **Run activity** — its runs, and its own outcome, cost, latency, error, and
change trends.
* **Instances** — every live replica, including which arm each belongs to.
* **Versions** — its deployed versions, with invocations split into production and shadow.
* **Evals** — its judge verdicts and score trend, when it has been evaluated. See
[Evaluations](/manage-your-agents/optimize/evaluations).
* **Skills & tools**, **Metadata**, **Permissions** — what it knows, what it is, and what it may do.
The header carries the lifecycle actions: **Disable** / **Enable**, **Archive** / **Unarchive**,
**Run agent**, **Chat**, **Edit**, and **Revert**. Disabling stops triggers from firing while
leaving manual and chat invocation working, which makes it the right way to quiet a misbehaving
agent without deleting anything.
Metadata carries **Last heartbeat**. When an agent reads offline and you want to know whether it
just went quiet or has been gone for a week, that is the field to read — before you go looking at
the worker.
## Reading the fleet in practice
Look at Outcomes & reliability and Changes together. A dip that coincides with version churn
points at a rollout.
Fleet composition and the just-went-offline call-out tell you whether you are looking at a
current outage or at history.
Use Worst error rate and Slowest agents to get from "the fleet is degraded" to two agent names.
Confirm the ranking against volume, then open the worst agent.
The run's evidence says what actually happened. If the same failure repeats,
Insights has already grouped it.
## Next steps
What a single run records, and how to read it.
Where the Cost figure comes from and how it is attributed.
Enable, disable, archive, roll forward, and roll back.
## Related topics
- [Troubleshooting](/reference/troubleshooting.md)
- [How Run works](/manage-your-agents/run/how-it-works.md)
- [Optimize — how it works](/manage-your-agents/optimize/how-it-works.md)
- [Manage a deployed agent](/manage-your-agents/build/manage-a-deployed-agent.md)
- [Model Evaluation](/manage-your-agents/optimize/model-evaluation.md)