Statuses

Component health

The Health column of the Components tab:

Health	Meaning
Healthy	Every replica the component should have is ready.
Degraded	Some replicas are ready, not all.
Unhealthy	No replica is ready.
Not installed	No running instance of the component is observed — usually an optional module this platform does not run. See Install a component.
Applied	The CRD bundle or the platform step: a rollout has applied it. They have no running instance, so they have no health; the version shown is the last one applied.
Not tracked	The CRD bundle or the platform step, with no applied version recorded yet.

The badge above the table sums it up:

Badge	Meaning
Platform: Healthy	Every required component is observed and healthy, and every platform image belongs to a known component.
Platform: Degraded	A required component is not healthy or not observed, or a platform image belongs to no known component. An optional module that is not installed does not count.
Platform: Unknown	No component has been observed yet.

Warnings on the Components and Dependencies tabs

These are reported beside the platform's health, not folded into it: each describes a platform that works but differs from its record.

Warning	Meaning
Unmanaged platform images: …	A Deployment labelled as part of the platform runs an image that belongs to no known component. A rollout will not manage it.
Cluster RBAC is not converged: …	The platform runs without some Kubernetes permissions the running release declares, for the reason shown. The effects appear elsewhere, most often as pre-upgrade checks that cannot read part of the cluster. The platform retries every 15 minutes, so a warning that clears by itself needs nothing; one that stays is worth raising with the reason it gives. A platform without a release feed shows it permanently.
Changed outside a rollout (Dependencies tab)	A third-party chart no longer runs the version the last rollout applied. Confirm the change was intended before you plan an upgrade. The tab shows a count while any chart is in this state.

Dependencies

The Dependencies tab lists the third-party charts the platform runs on, as their live Helm releases report them. It is empty until the release feed publishes dependencies for this platform.

Shown	Meaning
Deployed	A deployed Helm release of the chart is observed. Version shows the chart version and the application version.
Not observed	No deployed release of the chart is observed.
Manual upgrade	The chart is upgraded by hand through its vendor's procedure, never by a rollout. It stays listed so you can see when it is behind.

Plans

Status	Meaning
Validated	The plan passed validation and can be executed.
Draft	The plan has problems, listed above its batches, and cannot be executed.

Rollout states

A rollout's State, on the Rollouts tab and on its page:

State	Meaning
Running	In progress, or paused — the Phase tells which.
Succeeded	Every batch finished.
Failed	A batch did not finish within its time limit.
Cancelled	Ended with Cancel rollout. Components already upgraded stay upgraded.
RolledBack	Undone by a rollback, which is a rollout of its own. Nothing more can be done to it.

The Phase, shown on the rollout's page when it differs from the state, is what the operator reports. Paused is the one to act on: the page says why, and offers Resume and Cancel rollout — see When a rollout pauses.

The Rollouts tab lists the state recorded for each rollout. Open a rollout for its current state and phase.

On the rollout's page, each component in Progress is queued, rolling, done, failed or paused.

Installs

State	Meaning
Pending	Queued, or resumed and waiting to run.
Running	Working through its steps.
Succeeded	Every step succeeded.
Failed	A step failed. The install can be resumed from that step.

Platform drift scans

The badge of the Platform drift section on the After upgrading tab:

Status	Meaning
Not scanned yet	No scan has run since the Lifecycle module started.
Scanning	The first scan is running. A later scan runs with the previous result still shown.
No drift	The platform's own cluster objects match what the running release installs.
Changed by hand	Some settings differ; they are listed. See Settings changed by hand.
Scan failed	The scan could not finish; the reason is shown.
Unavailable	A scan cannot run here, typically because the operator is too old or the running release has no installer.

Admin bundle objects

Each object of the platform admin bundle, in the Platform admin bundle section and in the release.prerequisites check:

State	Meaning
Present	In place, as the bundle sets it.
Missing	Not in the cluster.
Changed by hand	In the cluster, but no longer what the bundle sets.
Unreadable	The Lifecycle module could not read it — typically on a cluster set up before the grant that lets it read existed. That grant is part of the bundle, so applying the bundle once fixes it.

When the bundle cannot be compared with the cluster at all, the section says so with the reason.

Clusters after an upgrade

The State of each cluster in the Clusters table of the After upgrading tab:

State	Meaning
Up to date	The cluster has the current access-control roles. Nothing to do.
Never applied	The cluster has never had them — normal for a cluster being set up.
Older version	A release changed them and the cluster still has the previous version.
Last attempt refused	Someone applied and the cluster said no; the reason is under Detail.
Needs a cluster administrator	The release adds rules no account on the cluster holds yet. The tab lists the rules and the commands to run once with a cluster-admin kubeconfig.
Ready — apply again to record	A cluster administrator has fixed it by hand. One more Apply to all clusters records it.

See Apply the access-control roles.