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.