See what is running with cub scout

1. Open your cluster map

You need: the cub CLI, kubectl and read access to a Kubernetes cluster. No cluster yet? Start with a local demo; this Guide is for an existing cluster.

First check the context name below. Stop if it is not the cluster you intend to inspect; select the right kubeconfig before continuing.

kubectl config current-context
cub plugin install confighub/cub-scout@v2.12.4
cub scout map

Your first result: an interactive terminal map of the objects Scout can read. Choose one familiar workload and look for its namespace and ownership. You have made no deployment or ConfigHub change.

If the map is empty or access is refused, check the context and permissions. Missing observations do not mean that the cluster is empty or healthy. Use the map’s displayed help for navigation.

2. Read one workload

Record three things: the object’s name and namespace, the controller or tool reported as its owner, and anything marked unknown. An owner might be Argo CD, Flux or Helm; it tells you where to investigate the next change.

For a readable summary outside the map, run:

cub scout doctor
cub scout gitops status

The first command identifies issues to investigate; the second shows what delivery controllers report. A healthy object alone does not prove the intended release was delivered or that the application works.

You can stop here. A useful result is knowing which system owns the workload and what to investigate next. No import or handover is required.

3. Choose where the change belongs

If Git and Argo CD or Flux own the object, inspect that source before changing live YAML. A reconciler can overwrite a direct edit. If ConfigHub holds the intended configuration, continue with the official ConfigHub GUI.

For a reviewed move into ConfigHub, use the Argo CD or Flux Guide. That is a separate decision from viewing your cluster.