# Worker & fleet health

The **Workers** tab shows every connected worker with live health and readiness,
so you always know what's available to run your work.

## What each card shows

- **Status dot + hostname** — connected/healthy/high‑load/offline.
- **RAM & CPU** bars — live resource use.
- **Harness chips** — per‑harness readiness from the "Say HI" probe, with the
  *reason* on failure (e.g. `⚠ opencode (out of balance)`).
- **Infra deps** — `gh`, `a2a`, `a2a-spawn` present/missing.
- **Active runs** and **last seen**.
- A **ready** badge when at least one harness has a working provider key.

## The fleet

Connect multiple workers and AM routes work across them:

- **Spawns** prefer probe‑ready workers that have the `a2a` / `a2a-spawn` tools.
- **Bus reads** target the worker actually running a given team.
- Unhealthy or disabled workers are skipped.

## Managing workers

- **Disable** a worker from the tab to take it out of rotation without
  uninstalling.
- **Remove** by uninstalling on the host — see [Add a worker](/docs/add-worker).

## Readiness, not just connectivity

A connected worker can still be unable to do real work (no key / empty balance).
The chips and the **Test** button tell you the truth — see
[Verify readiness](/docs/verify-readiness).

## Notifications

Set an **alert webhook** (`ALERT_WEBHOOK_URL`, a Slack or Discord incoming
webhook) and AM pushes a message when:

- a repo hits **3 consecutive failed runs** (re‑armed after the next success),
- a run's **verification gate stays red** (`verify_failed` → draft PR), or
- an account's **daily spend cap is reached** (autonomous runs paused).

The payload works for **both** Slack and Discord, and each event fires once (no
re‑spam on the scheduler's periodic checks).

## Related

- [Add a worker](/docs/add-worker) · [Verify readiness](/docs/verify-readiness)
- [Worker not ready](/docs/worker-not-ready)