# istioctl verify-install: Confirm Istio Health

> istioctl verify-install checks that an Istio installation matches its manifest and is running correctly. Reference for -f, revision, and the mismatch errors in CI.

Source: https://latchkey.dev/learn/command-reference/istioctl-verify-install  
Updated: 2026-06-30

istioctl verify-install checks that the deployed Istio control plane matches the expected manifest and that its resources are healthy.

Right after istioctl install, verify-install gives you a pass/fail signal that the control plane rolled out cleanly, which is exactly what a deploy job wants to gate on.

## What it does

istioctl verify-install compares the resources Istio should have created (from a profile or IstioOperator file) against what is actually in the cluster, and reports each as found or missing. Run without -f, it verifies the currently installed control plane is healthy.

## Common usage

```Terminal
# verify the running control plane
istioctl verify-install
# verify against the manifest you installed from
istioctl verify-install -f istio-operator.yaml
```

## Options

| Flag | What it does |
| --- | --- |
| -f <file> | Verify the cluster against this IstioOperator manifest |
| --revision <name> | Verify a specific control-plane revision |

## In CI

Run verify-install as the last step of the install job; a non-zero exit means the rollout is incomplete and the pipeline should stop before it deploys workloads that depend on the mesh.

## Common errors in CI

"Istio installation NOT verified" lists resources that are missing or not ready, for example "Deployment: istiod.istio-system not ready". That usually means an image pull failure or insufficient resources on the nodes. A mismatch against -f means the live install drifted from the manifest, often a manual kubectl edit.

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

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### istioctl verify-install: Confirm Istio Health?

Right after istioctl install, verify-install gives you a pass/fail signal that the control plane rolled out cleanly, which is exactly what a deploy job wants to gate on.

### What it does?

istioctl verify-install compares the resources Istio should have created (from a profile or IstioOperator file) against what is actually in the cluster, and reports each as found or missing. Run without -f, it verifies the currently installed control plane is healthy.

### In CI?

Run verify-install as the last step of the install job; a non-zero exit means the rollout is incomplete and the pipeline should stop before it deploys workloads that depend on the mesh.

### Common errors in CI?

"Istio installation NOT verified" lists resources that are missing or not ready, for example "Deployment: istiod.istio-system not ready". That usually means an image pull failure or insufficient resources on the nodes. A mismatch against -f means the live install drifted from the manifest, often a manual kubectl edit.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt