Find and read a run#

  1. Open Runs or follow a run from its project. Filter by the relevant state and search context.
  2. Check the project, target, source revision and requested mode before reading the stage timeline.
  3. Inspect fetch/render results, then the plan and policy decision.
  4. If apply occurred, inspect execution and verification evidence rather than relying only on the overall badge.
  5. Use the event history and support context identifiers to correlate the attempt with operator diagnostics.
This demonstration run has reached Approval. Fetch, Render, Plan and Policy have completed; Apply and Verify are still pending.
This demonstration run has reached Approval. Fetch, Render, Plan and Policy have completed; Apply and Verify are still pending. View full size ↗

Review the plan#

The plan explains intended object actions and associated evidence. Review additions, changes, deletions and no-op objects. Verify the resolved commit and target. A plan digest identifies reviewed evidence; an approval for an older digest is not an approval for a new plan.

If the plan has not been produced yet, the plan panel can be empty because an earlier stage is pending or failed. That is different from a completed plan containing no changes.

The Changes panel groups planned resource actions and risk indicators. Inspect each relevant object before deciding whether the change is appropriate.
The Changes panel groups planned resource actions and risk indicators. Inspect each relevant object before deciding whether the change is appropriate. View full size ↗

Retry, cancel, rollback and reconcile#

ActionMeaning and follow-up
RetryStarts another permitted attempt. Inspect the new run and its inputs; do not treat it as resuming an arbitrary partial mutation.
CancelRequests cancellation. Changes already sent to Kubernetes are not automatically undone. Check final state and events.
RollbackCreates a recovery delivery from available retained evidence. Review the resulting run and its verification.
ReconcileUse when the server offers recovery for an uncertain or incomplete outcome. Establish live state before assuming success or failure.

The UI exposes actions according to the server-provided capabilities for that run. If an action is unavailable, inspect its state and permissions instead of manually changing database state.

Unknown outcome#

An unknown-outcome run means the system cannot safely claim the final result of the attempt. Inspect the target resources, execution receipts and retained artifacts. Use the offered recovery flow and operator evidence. Blindly retrying a mutation can compound an uncertain result.

Example: review a Kubernetes image change before deployment#

Suppose a Git change updates a Deployment image. Before allowing that change onto the target cluster, open the corresponding run and review these items:

  1. Identity: confirm the resolved commit, project, target cluster and namespace. A familiar project name is not sufficient if its destination changed.
  2. Scope: open Changes and inspect the affected resource actions. If an image update also proposes deletions or unrelated changes, investigate those before proceeding.
  3. Intent: compare the resource evidence with the reviewed Git change. Check image references, configuration and any availability-sensitive changes.
  4. Policy: inspect the policy result and required approvals. A successful render is not policy approval.
  5. Decision: follow the approval process if the run is awaiting approval. If its plan changes, review the current evidence again.
  6. Outcome: after Apply, inspect Verify and the live workload. Check readiness and container logs before declaring the rollout healthy.

This is a review example, not a claim about a completed customer deployment. The screenshot above shows a run waiting for approval; Apply and Verify have not completed in that capture.

Know where a run stopped#

Stage or stateInvestigation
Fetch or Render failedCheck source credentials, revision, repository path and renderer configuration. There may be no plan to review yet.
Policy deniedRead the decision and correct the change or reviewed policy configuration. Repeating the same run does not resolve a policy violation.
Awaiting approvalCheck required approvers and the current plan. Waiting for a human decision is different from an execution failure.
Apply failed or outcome unknownInspect retained evidence and the live target before retrying. Some mutations may already have reached Kubernetes.
Verify failedInvestigate workload conditions and events. Applied objects do not guarantee a healthy application.

Start with the first-project guide if the source, target or renderer has not yet been configured.