Skip to content

Check resource status

This content is for the v0.1 version. Switch to the latest version for up-to-date documentation.

Use kix status to compare a cluster definition with the resources currently running in Kubernetes and see their readiness state.

Run the command with the cluster name:

Run in kix-examples/
❱ kix status how-to-application
 NAME                             NAMESPACE    KIND                      READY  STATUS    AGE 
 how-to-application-aq1zdgf9gsnb  _cluster     Activation                True   Active    2s  
 activations.kix.run              _cluster     CustomResourceDefinition  True   Active    38s 
 packageinstances.kix.run         _cluster     CustomResourceDefinition  True   Active    38s 
 how-to-app                       _cluster     Namespace                 True   Active    38s 
 kube-system                      _cluster     Namespace                 True   Active    43s 
 preview                          how-to-app   ConfigMap                 True   Active    38s 
 production                       how-to-app   ConfigMap                 True   Active    38s 
 production-health-script         how-to-app   ConfigMap                 True   Active    38s 
 preview                          how-to-app   Deployment                True   1/1       38s 
 production                       how-to-app   Deployment                True   2/2       38s 
 production-health                how-to-app   Job                       True   Complete  10s 
 preview                          how-to-app   PackageInstance           True   Active    12s 
 production                       how-to-app   PackageInstance           True   Active    2s  
 preview                          how-to-app   Service                   True   Active    12s 
 production                       how-to-app   Service                   True   Active    12s 
 platform-dns                     kube-system  PackageInstance           True   Active    36s

Kix reads the cluster using the selected kubectl context. The output groups resources by package and reports the state Kix observes for each one.

Use this after a deployment to confirm that workloads remain ready, Jobs have completed, and the active cluster resources are still present.

Pass --context when the desired cluster is not the current kubectl context:

Run in kix-examples/
❱ kix status how-to-application --context kind-kix-demo

The context controls which Kubernetes API Kix reads. The --flake option independently controls which cluster definition it evaluates:

❱ kix status how-to-application --flake ./infrastructure --context kind-kix-demo

Status is a summary. When a resource is not ready:

  1. Note its kind, name, and namespace in the status output.
  2. Inspect it with kubectl describe.
  3. Read Pod or Job logs where applicable.
  4. Run kix diff to determine whether the live resource differs from the desired manifest.

For example:

Run in kix-examples/
❱ kubectl describe deployment production -n how-to-app Show output
Name:                   production
Namespace:              how-to-app
CreationTimestamp:      Thu, 10 Sep 2026 02:21:13 +0200
Labels:                 app.kubernetes.io/instance=production
                        app.kubernetes.io/managed-by=kix
Annotations:            deployment.kubernetes.io/revision: 1
                        kix.run/activations: aq1zdgf9gsnbdpc8hwkma69l8ipalqpx
                        kix.run/applied-hash: f8951e6d596e9e15864180382df893740fbb17a6b7db935b56689c601b024b60
                        kix.run/depends-on: 4x75h2z7rsj3dvrdg9vzqc8l789xvm4w,8767b7nzgc1x5bpfa9gv71cpk9z8h0iw
                        kix.run/identity-hash: 22q0r4mc7ndy997yyffbxgas246g0zhq
                        kix.run/package: production
                        kix.run/package-namespace: how-to-app
Selector:               app.kubernetes.io/instance=production,app.kubernetes.io/name=production
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app.kubernetes.io/instance=production
           app.kubernetes.io/name=production
  Containers:
   nginx:
    Image:      docker.io/library/nginx:1.27-alpine
    Port:       80/TCP (http)
    Host Port:  0/TCP (http)
    Limits:
      memory:  64Mi
    Requests:
      cpu:      10m
      memory:   16Mi
    Readiness:  http-get http://:http/ delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      APP_ENV:  production
    Mounts:
      /usr/share/nginx/html from content (ro)
  Volumes:
   content:
    Type:          ConfigMap (a volume populated by a ConfigMap)
    Name:          production
    Optional:      false
  Node-Selectors:  <none>
  Tolerations:     <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   production-85577f7474 (2/2 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  33s   deployment-controller  Scaled up replica set production-85577f7474 from 0 to 2

The health-check Job’s logs say whether the post-deploy probe passed:

Run in kix-examples/
❱ kubectl logs job/production-health -n how-to-app
ok    GET http://production.how-to-app.svc.cluster.local:80

status reports observed health. It does not reapply resources or change the active activation.