# flux reconcile: Force an Immediate Sync

> flux reconcile triggers an immediate reconciliation instead of waiting for the interval. Reference for source vs kustomization, --with-source, and CI gating.

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

flux reconcile triggers an immediate reconciliation of a Flux object instead of waiting for its configured interval.

In a pipeline you do not want to wait minutes for the next interval. reconcile forces Flux to pull and apply now, then reports the result.

## What it does

flux reconcile annotates a Flux object to request an immediate reconciliation and waits for it to finish. You reconcile by kind: source git, kustomization, or helmrelease. --with-source first refreshes the underlying source so you apply the latest commit.

## Common usage

```Terminal
# pull the latest commit and apply it
flux reconcile kustomization podinfo --with-source
# refresh just a source
flux reconcile source git podinfo
# force a Helm upgrade
flux reconcile helmrelease podinfo --with-source
```

## Options

| Flag | What it does |
| --- | --- |
| source git <name> | Reconcile a GitRepository source |
| kustomization <name> | Reconcile a Kustomization |
| helmrelease <name> | Reconcile a HelmRelease |
| --with-source | Also reconcile the upstream source first |
| -n <namespace> | Namespace of the Flux object |

## In CI

After pushing a commit, run flux reconcile kustomization <name> --with-source so the pipeline deploys the exact commit it just pushed and blocks until reconciliation finishes. The command exits non-zero if reconciliation fails, so it gates the job.

## Common errors in CI

"✗ Kustomization reconciliation failed: ..." surfaces the same build/apply errors as the controller logs. "✗ no GitRepository found ..." or "kustomization not found" means a wrong name or namespace (pass -n). A reconcile that succeeds but applies an old commit means you forgot --with-source.

## 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 reconcile: Force an Immediate Sync?

In a pipeline you do not want to wait minutes for the next interval. reconcile forces Flux to pull and apply now, then reports the result.

### What it does?

flux reconcile annotates a Flux object to request an immediate reconciliation and waits for it to finish. You reconcile by kind: source git, kustomization, or helmrelease. --with-source first refreshes the underlying source so you apply the latest commit.

### In CI?

After pushing a commit, run flux reconcile kustomization <name> --with-source so the pipeline deploys the exact commit it just pushed and blocks until reconciliation finishes. The command exits non-zero if reconciliation fails, so it gates the job.

### Common errors in CI?

"✗ Kustomization reconciliation failed: ..." surfaces the same build/apply errors as the controller logs. "✗ no GitRepository found ..." or "kustomization not found" means a wrong name or namespace (pass -n). A reconcile that succeeds but applies an old commit means you forgot --with-source.

---

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