consul members: List Cluster Members

By Kaveh Alemi·Latchkey

consul members shows the agents the local Consul agent knows about through gossip, with each member address, status, and role.

A quick consul members after bootstrapping confirms every server and client joined and is alive, which is the readiness signal a deploy job wants.

What it does

consul members queries the local agent for the gossip pool membership and prints each node with its address, status (alive, left, failed), type (client or server), build, protocol, and datacenter. It reflects gossip state, not the full service catalog.

Common usage

consul members
# include extra fields like tags
consul members -detailed
# filter by status
consul members -status alive

Options

In CI

After starting a Consul cluster in a test, poll consul members and assert the expected count are alive before proceeding. Use -status alive to filter out members still joining.

Common errors in CI

"Error connecting to Consul agent: ... connection refused" means no agent is listening on the default 127.0.0.1:8500, so the agent did not start or is on another address; set -http-addr or CONSUL_HTTP_ADDR. A member stuck in "failed" status has left the gossip pool, usually a crashed or unreachable node.

Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes

Frequently asked questions

Related guides

References

• GitHub Actions documentation