# Check live resources for drift

Use `kix drift` to find changes made to fields Kix manages after the resources
were deployed.

## Run the drift check

Run the command without a cluster name:

<Command {...scaledDeployment} />

The captured example has one deliberate change: the production Deployment was
scaled from two replicas to one with kubectl. The output identifies
`spec.replicas` as drifted and names kubectl as the field manager that changed
it.

`drift` reads Kix-managed resources from the selected Kubernetes context. It
does not need a source checkout, cluster name, or Nix evaluation because each
deployed resource carries the information needed for the comparison.

## Read the verdicts

The complete output assigns each managed resource one of four verdicts:

| Verdict | Meaning |
| --- | --- |
| `in-sync` | The fields managed by Kix still match their applied content |
| `drifted` | One or more managed fields changed |
| `unstamped` | The resource predates drift stamps and cannot yet be compared |
| `no-fieldset` | Kubernetes did not retain the managed-field data needed for the check |

When possible, a drifted result names the other field manager, operation,
subresource, time, and field paths involved. A result containing any drifted
resource exits with status 1.

## Select a Kubernetes context

Pass `--context` to inspect a context other than the current one:

<Command commands={["kix drift --context kind-kix-demo"]} />

Use JSON when another program will process or store the report:

<Command commands={["kix drift --output json > drift.json"]} />

`kix drift` checks field content. Use [Check cluster health](/docs/how-to/operate-a-cluster/check-cluster-health/)
when you need to verify that the active dependency graph is still intact.

:::note[Next step]
Use [Reconcile drift](/docs/how-to/operate-a-cluster/reconcile-drift/) to
reapply the desired manifests after reviewing the report.
:::