Workflow run

Watch a live workflow run, answer questions, and repair or replay steps.

The workflow run page at /workflows/runs/{id} is the live view of one execution: which step is running, what happened at each attempt, what is in session data, and what the run has touched. It is also where you intervene when a run needs you.

Header and controls

The run number, its status badge, and its generation — replays append a new generation rather than overwriting the original attempts.

Control	Available when
Pause	The run is executing
Resume	The run is paused
Cancel run	The run has not reached a terminal state
Refresh	Always

Waiting for worktree admission

A queued run shows a live Queue card before the run graph. It displays the combined workflow, Plan, and Session admission order for the run’s worktree. The current workflow run is highlighted, and workflow rows carry their Exclusive, Non-exclusive, or Excluded admission mode.

The card updates as workflow and AI run state changes. It disappears after this run is admitted and starts scheduling.

Queue position is an effective display order, not a promise that every row starts serially. Plans and Sessions have separate lanes and may advance independently until an exclusive workflow becomes the admission barrier.

Why a run is waiting

A run that is not finishing shows a Waiting on card above the run graph, naming every step that is currently sitting still and why.

Steps sit still for two different reasons, and the card separates them:

	What it means	What resolves it
Parked	The step handed work to something outside the runtime — an agent job, a Plan or Session, a build, a command — and is waiting for it to report back. It holds no worktree or codebase lock while it waits.	The external work finishing, or the wait timing out
Held	The step never started, because the codebase or worktree it needs is busy with another run.	The other run releasing it

Each parked step lists what it is Waiting on — a link straight to the job, Plan, or Session — along with how long it has been waiting, when it Times out, and when the runtime next checks. A held step shows the contention that is blocking it instead.

A parked step is normal, not stuck. Use Times out to tell the difference: a wait that is still well short of its timeout is simply slow external work, while one approaching it will fail the step and surface a real error.

Live run graph

The published graph is annotated with live state — which node succeeded, failed, is waiting, or is active. It updates as the run progresses. For command-output matching, the graph shows the actual execution of each emitted match branch instead of the dormant scheduling template; the source command continues to display its own terminal state separately.

Answering a question

When a step raises a question, the run moves to Waiting and the question appears on this page, labeled with the step that asked it. Pick from the offered buttons or type a Custom answer, then Answer.

The same question also appears in the Action Center, so you can answer without hunting for the run. Answering in either place resolves it.

Repairing blocked session data

A run goes Blocked when a step cannot proceed with the session data it has — a missing key, a wrong shape, a value an upstream step failed to write.

Repair blocked session data applies an atomic JSON merge patch to the run’s session data and then resumes scheduling from the blocked step. Enter the patch, then Apply repair.

A merge patch only describes what changes. Supply the keys you want to add or correct; everything you leave out is untouched.

Replaying and rewinding

Replay re-executes part of a run from a chosen step.

1. Select a step

   Choose the step to rewind to.

2. Prepare the replay

   Prepare replay computes a preview: how many descendant steps will re-run and which ones they are, by name; how many other steps keep their current results; and which external effects the original pass already caused.

3. Choose how to handle Git state

   • Replay without Git restore — leave the working tree exactly as it is.
   • Restore Git and replay — return the worktree to the state captured at that step first.
   • Stash, restore, and replay — stash current changes, then restore and replay.

External effects are retained and will not be reversed. A replay does not un-merge a pull request, un-transition a Jira ticket, or un-send a notification — the preview lists exactly what the first pass already did so you can decide before committing.

Replaying creates a new append-only generation. The original attempts stay in history, marked Superseded.

Steps a replay did not re-run

A replay writes a row for every step of the graph, not just the ones it re-executes. Steps outside the replayed branch are carried forward from the previous generation with their earlier result attached, and are marked so you can tell them apart:

• In the run graph they carry a Reused marker and a dimmed status badge, and they show no generation label — the generation belongs to the replay, not to a result that was produced earlier.
• In Step attempts their Phase reads Reused and the row is dimmed. Steps queued for the replay itself read Queued for replay until they start.

Tabs

Timeline

Every event the run has emitted, in order. Event types include run lifecycle events — started, pausing, paused, resumed, cancelled, succeeded, failed, data repaired, replayed — and step events: succeeded, failed, blocked, waiting, wait resolved, retry scheduled, recovery blocked, and waiting for codebase.

A Step waiting event names the step and what it parked on. Its matching Wait resolved event reports how long the wait lasted and what freed it — the external work reporting back, the runtime’s own poll, your answer to a question, or a delay elapsing.

Step attempts

One row per attempt with Step, Status, Phase, Generation, Iteration, Attempt, Duration, and Error. Phase is the scheduler’s own sub-state for the attempt — including Reused and Queued for replay after a replay, and Waiting for codebase or Waiting for worktree while a step is held. Iteration distinguishes passes through a For each body; attempt distinguishes retries of the same step.

A parked attempt notes what it is waiting on beneath its status badge.

Attempt statuses include Pending, Ready, Running, Waiting, Blocked, Succeeded, Failed, Skipped, Superseded, and Timed out.

Session data

The run’s current session document — the JSON that steps read from and write to. This is what the repair patch modifies.

Resources

Everything this run is linked to — worktrees, builds, pull requests, tickets, AI runs, command runs — each with an Open link to its own page.

Related pages

Workflow details

The published version, its graph, and recent runs.

Action Center

Every run that is waiting, blocked, or failed, in one queue.