Skip to main content
A run is one execution of a published workflow version. This guide covers run lifecycle, controls, observability, and the Command Center inbox.

​
Starting a run

Start runs from:
  • Workflow Studio — Run button on a published workflow
  • REST API — POST /v1/workflows/{id}/command with command start
  • Inbound webhooks — Signed external triggers (see Inbound webhooks)
  • Autopilot — Chat command to run a workflow by name
Runs inherit the workflow’s published graph and input params. MCP credentials resolve from each step’s instance_id and catalog instance wiring.

​
Run controls

Send commands via the API or Studio run panel: Stopping immediately cancels in-flight MCP tool calls. LLM calls are best-effort cancelled.

​
Observing runs

​
Workflow Studio

The run panel shows a live event log: step started, tool result, LLM output, failures, and pauses. Subscribe via WebSocket for sub-second updates. Timeline tab (Execution panel) — Gantt-style view of step durations in execution order, nested agent activity from run events, composite loop estimates, and run state markers. See Execution Timeline. Context tab — static execution-order graph (step nodes + wiring) with an Open graph modal for interactive pan/zoom. See Execution Timeline — Context graph.

​
Analytics

The Analytics page (/analytics) shows workspace-level metrics:
  • Live and recent runs
  • Success rate
  • Steps executed
  • Credits consumed
  • Usage timeseries
Project contributors can access analytics APIs at /v1/analytics/*.

​
Run APIs

​
Command Center

Command Center (/command-center) is your workspace-wide run inbox for approvals, active runs, and recent failures. See the dedicated Command Center guide for daily operator workflows, run controls, and what to do when a run looks stuck.

​
Failure handling

When a step fails, the run becomes failed (terminal). The canvas and event log show distinct step outcomes — not stale “Processing” or “Pending” on branches that cannot complete.

​
Step status badges

Parallel example: branch A fails on missing credential; branch B (still calling the LLM) shows Cancelled; join step C shows Skipped (Blocked).
Cancelled on a step is not the same as run status stopped. Operator Stop marks in-flight steps differently (RUN_STOPPED). Step failure uses fail-fast cancellation.
Failed runs do not resume today. Fix the root cause (model, credential, tool args), publish if the graph changed, and start a new run. Planned checkpoint/retry flows are described in Run recovery (roadmap). Review the event log for error messages and tool responses. Persisted event types include step_failed, step_cancelled, and step_completed with skipped: true and reason: "blocked" — see Run event types.

​
Credits and metering

Each action (LLM tokens, MCP tool calls, workflow steps) consumes credits according to your plan’s action pricing. Usage appears in Analytics and on the billing usage page.