Skip to main content
A deployment is generated by Control Plane, never created by you. A workload has one deployment per location its GVC spans, named after that location, and every field on it is read-only.

Example

Status

Deployment version

Each entry in status.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 in status.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 overwrites status.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 requires view on its workload.

CLI

Add -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.