Skip to main content
Every object KubeStacks shows gets a status: a short label that says what’s going on, like CrashLoopBackOff or Degraded, and a health level behind it. The health level decides the color and icon, where the object sorts, and which filter it’s counted under.

Five levels

Lists sort by health, in that order, so the most urgent things are always at the top. The chips above a list count each level and filter by it. Pick Failing and Warning together to see only the problems. Some kinds name the chips in their own words: on Pods they’re Running, Starting and Completed instead of Healthy, In progress and Inactive, and on Events, Normal. In the app, a status always comes with an icon and its label, never color alone, and the colors are reserved for health. Charts use a palette checked for color blindness, in both themes.

Pods

A pod’s status is the most specific reason KubeStacks can find. It checks, in order: Init containers are checked before the others, so a pod stuck initializing says why. Hover a status for the message behind it.
A container that was killed for running out of memory and restarted shows Running again, but its card in the pod’s details says Last terminated: OOMKilled (exit code 137). Watch the Restarts column for pods like this.

Workloads

Deployments, StatefulSets, DaemonSets and ReplicaSets compare ready pods with the pods they want:

The rest of the built-in kinds

Services, ingresses, network policies, ConfigMaps, Secrets and storage classes have no status: there’s nothing about them to be healthy or not.

Custom resources

Kinds that KubeStacks has no page for, custom resources included, get a status read from the conventions most controllers follow. A view can spell out its own rules instead, and when one of them applies, it wins. Otherwise KubeStacks checks, in order:
1

Being deleted

The object has a deletion timestamp: Terminating.
2

Suspended or paused

spec.suspend is set: Suspended. spec.paused is set: Paused.
3

Stalled

A Stalled condition is True, as kstatus defines it: critical, labeled with its reason, or Stalled.
4

Not ready

The object has a readiness condition: the first of Ready, Available, Healthy, Programmed, Established, Succeeded or Accepted, in that order. If it’s False, and the controller isn’t still working on it, the object is critical, labeled with the condition’s reason, or with Not ready (Not available, and so on).
5

Still working on it

A Reconciling or Issuing condition is True, or the controller hasn’t seen the latest spec yet (status.observedGeneration is behind metadata.generation): progressing, labeled with the condition’s reason, or Reconciling.
6

Ready

The readiness condition is True: healthy, labeled with its name, like Ready. If it’s Unknown, progressing.
7

A health, phase or state

Without a readiness condition, status.health.status (as Argo CD writes it), status.phase or status.state is shown as it is, and its words decide the level. The first row that matches wins:
A phase that matches none of them is neutral. An object with none of these fields shows Unknown, and a kind whose objects have none gets no status column at all.

Write a view

Give a custom kind status rules of its own.

Finding things

Filter any list by health, text or labels.