Skip to content
LatchkeyLatchkey home

meshctl check: Validate Gloo Mesh Health

meshctl check runs health and config validations against a Gloo installation and reports each check as OK or a failure.

For Gloo Mesh and Gloo Gateway, meshctl check is the equivalent of linkerd check or cilium status: one command that tells you if the install is healthy enough to proceed.

What it does

meshctl check inspects the Gloo management components (the management server, agents, and CRDs), verifies the deployments are ready, and validates that the applied Gloo config has no reported errors, printing a checklist with OK or a failure reason for each item and exiting non-zero on failure.

Common usage

Terminal
meshctl check
# point at a specific kubeconfig/context
meshctl check --kubeconfig $KUBECONFIG --kubecontext mgmt

Options

FlagWhat it does
--kubeconfig <path>Kubeconfig file to use
--kubecontext <name>Context to run the checks against
-n, --namespace <ns>Namespace Gloo is installed in

In CI

Run meshctl check after installing Gloo and after applying gateway or mesh config; a non-zero exit means a component is unhealthy or the config has errors, so the deploy should stop. Pass --kubecontext explicitly in multi-cluster pipelines so you check the intended cluster.

Common errors in CI

A failing line reads like "X Gloo ... deployment is not ready" or lists a config resource with a rejected/pending status. "failed to find any Gloo ... in namespace" means Gloo is not installed there; set -n. "error: no configuration has been provided ... KUBECONFIG" means the kube context is not set for the runner.

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.

Terminal
# 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

meshctl check: Validate Gloo Mesh Health?
For Gloo Mesh and Gloo Gateway, meshctl check is the equivalent of linkerd check or cilium status: one command that tells you if the install is healthy enough to proceed.
What it does?
meshctl check inspects the Gloo management components (the management server, agents, and CRDs), verifies the deployments are ready, and validates that the applied Gloo config has no reported errors, printing a checklist with OK or a failure reason for each item and exiting non-zero on failure.
In CI?
Run meshctl check after installing Gloo and after applying gateway or mesh config; a non-zero exit means a component is unhealthy or the config has errors, so the deploy should stop. Pass --kubecontext explicitly in multi-cluster pipelines so you check the intended cluster.
Common errors in CI?
A failing line reads like "X Gloo ... deployment is not ready" or lists a config resource with a rejected/pending status. "failed to find any Gloo ... in namespace" means Gloo is not installed there; set -n. "error: no configuration has been provided ... KUBECONFIG" means the kube context is not set for the runner.

Related guides

References

Run this faster and cheaper on Latchkey managed runners - self-healing included. Start free → 30-day trial · No credit card