# Fleet Console

Fleet Console relates resource use to processes, service ownership, leases, health checks and operator messages. Use those relationships to understand why background work exists before taking a maintenance action. Start with Quick View for an observation, then follow the process or managed service that owns the work.

**Fleet Console overview with CPU, memory, top processes and the process map**

[Open the interactive Studio scene](/docs/studio-artifacts/docs-scenes/fleet-console.html)

## Start with an observation

[Find what is keeping your Mac busy](/docs/fleet-console/quickstart) is a read-only first task. You will open Quick View, follow a resource into a timed chart, and select a process. You do not need to stop anything to learn which work is consuming resources.

Fleet Console requires macOS 14 or later. This guide assumes you already have a supported copy installed. Local monitoring and service control are free; linked-computer access is separate from local use. The [maintained project documentation](https://github.com/janestreetshiller/fleet-console) describes the application and its source license.

## Monitoring is not control

A process visible in the dashboard is not necessarily a service the controller may manage. Work launched through `fleetctl` has a recorded owner, purpose and lease. A claimed process has a record but remains observation-only. An unmanaged process was started outside that supervision. An owner label records attribution; it is not a new grant of operator permission.

The controller's pause, resume, stop and restart controls apply to controller-launched services. A command typed into a terminal does not become supervised merely because the terminal appears inside Fleet Console.

## Maintain managed work deliberately

### Check ownership and lease

[Distinguish launched, claimed and unmanaged work](/docs/fleet-console/launched-claimed-and-unmanaged-work), then [review the lease](/docs/fleet-console/renew-a-lease-or-let-work-expire). A process name alone does not establish why it is running or who may control it.

### Inspect before stopping

[Read service logs and events](/docs/fleet-console/read-service-logs-and-events) and [check health separately from running state](/docs/fleet-console/running-is-not-the-same-as-healthy). Use [pause, resume, restart or stop](/docs/fleet-console/pause-resume-restart-or-stop-safely) only for the intended controller-launched service. Do not stop unrelated work as a diagnostic shortcut.

### Keep the operator in the loop

[Ask an operator and collect the reply](/docs/fleet-console/ask-an-operator-and-collect-the-reply) when a decision is missing. An operator message records communication; it is not automatic permission for an agent to change another service.

## Interpret the evidence

A running process, a listening port and a passing health check are independent facts. No configured check means **Running (unverified)**, not healthy. An unavailable temperature, fan or battery reading is not zero; support depends on the hardware. Old observations do not establish present behavior.

After the first inspection, use [fleetctl reference](/docs/fleet-console/fleetctl-reference) to understand an existing service record. If observations disappear, preserve the process and collect diagnostics before attempting any repair.