Example
Status
Deployment version
Each entry instatus.versions is one version of the workload as it exists in this location. During a rolling update two entries appear at once.
Container status
Job executions
Cron workloads record their run history instatus.jobExecutions, capped at the workload’s job.historyLimit.
A run reaches
removed when it was deleted before finishing, usually because job.concurrencyPolicy is Replace and the next run was due, or because job.activeDeadlineSeconds elapsed.
Reading a rollout
Compare the two version numbers first.
A location switched off through
spec.localOptions reports ready: false with the message This workload location is deactivated because suspend is set to true. That is the expected state, not a failure.
Stale and expired deployments
Each location reports in on a schedule. When a report is overdue by more than 45 minutes, Control Plane overwritesstatus.message with Status details are stale, so an unreachable location cannot present old data as current. Suspended locations are exempt, since they have nothing to report.
A record untouched for 24 hours is dropped from the list entirely. A workload whose deployments are missing rather than unhealthy has not been deployed to those locations recently.
Permissions
Deployments carry no permissions of their own. Reading one requiresview on its workload.
CLI
-o json or -o yaml for the full object; the default table view shows readiness per location. See the workload CLI reference.
API
The GVC-wide listing returns one item per workload and location pair. Deployment names repeat across workloads, so use each item’s
workload link to tell them apart.