# flux get kustomizations: Check Sync Status

> flux get kustomizations lists Kustomizations with their ready status and last applied revision. Reference for -A, --status-selector, and scripting checks.

Source: https://latchkey.dev/learn/command-reference/flux-get-kustomizations  
Updated: 2026-06-30

flux get kustomizations lists every Kustomization with its Ready status, applied revision, and last message.

To confirm Flux finished applying after a push, get kustomizations shows whether each one is Ready and which revision it applied.

## What it does

flux get kustomizations prints a table of Kustomizations: name, Ready condition, applied revision, and the latest status message. flux get all shows sources, kustomizations, and helmreleases together. -A spans all namespaces.

## Common usage

```Terminal
flux get kustomizations -A
# only show ones that are not ready
flux get kustomizations -A --status-selector ready=false
# everything Flux manages
flux get all -A
```

## Options

| Flag | What it does |
| --- | --- |
| -A, --all-namespaces | List across all namespaces |
| --status-selector ready=false | Filter by Ready condition |
| -n <namespace> | Limit to one namespace |
| (get all) | Show sources, kustomizations, and helmreleases |

## In CI

Use --status-selector ready=false to assert nothing is broken: an empty result means every Kustomization reconciled. The applied revision column lets you confirm Flux is on the commit your pipeline just pushed.

## Common errors in CI

"✗ no Kustomizations found in <ns> namespace" usually means the wrong namespace (Flux defaults to flux-system); add -A or -n. A Ready=False row shows the reconcile error in the message column. "the server doesn't have a resource type ... kustomizations" means Flux CRDs are not installed in that cluster.

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

### flux get kustomizations: Check Sync Status?

To confirm Flux finished applying after a push, get kustomizations shows whether each one is Ready and which revision it applied.

### What it does?

flux get kustomizations prints a table of Kustomizations: name, Ready condition, applied revision, and the latest status message. flux get all shows sources, kustomizations, and helmreleases together. -A spans all namespaces.

### In CI?

Use --status-selector ready=false to assert nothing is broken: an empty result means every Kustomization reconciled. The applied revision column lets you confirm Flux is on the commit your pipeline just pushed.

### Common errors in CI?

"✗ no Kustomizations found in <ns> namespace" usually means the wrong namespace (Flux defaults to flux-system); add -A or -n. A Ready=False row shows the reconcile error in the message column. "the server doesn't have a resource type ... kustomizations" means Flux CRDs are not installed in that cluster.

---

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