Read service logs and events

Use captured output and the controller's event history to reconstruct one service's behavior. Start with its exact service ID or unambiguous name and the bundled CLI on PATH. Logs can contain credentials and private application data; inspect locally and redact before sharing.

Read one service

Replace SERVICE_ID with the record you have inspected:

fleetctl show "SERVICE_ID"
fleetctl logs "SERVICE_ID"
fleetctl logs "SERVICE_ID" --err
fleetctl events "SERVICE_ID"

logs returns the tail of captured stdout, or stderr with --err; it is not a claim of complete output retention. events supplies the controller's recorded timeline. Keep application output and controller actions separate: a program can print “ready” before a configured health check passes.

Check the sequence

Compare the service identity, observation times and relevant launch, lease or control events with the output you are investigating. A crashed service can still have useful logs. An unknown service passed to events is an error, not permission to silently use unrelated global history.

A claimed process did not have its output descriptors captured by this controller. Its logs remain wherever it was originally started. Missing captured output for that class is not evidence that the process was silent.

Preserve historical scope

If the controller is unavailable, the maintained CLI supports reading existing event history without a live snapshot:

fleetctl events "SERVICE_ID" --offline

That history is recorded evidence, not current process state. Keep its time and scope when writing a support report. Do not prune records or delete the registry to make diagnostics look clean.

Continue with data locations. The CLI reference documents log options and offline history.