Running and monitoring

Every run of a workflow is recorded as an execution. Starting a run returns immediately with an execution id — the pipeline itself executes asynchronously — and the console drops you straight onto the execution page, which refreshes itself while the run is in progress.

Starting a run

On the workflow detail page (Build → Workflows → your workflow), click Run. What happens next depends on the pipeline's declared inputs:

• If the pipeline references $userinput.<key> placeholders, the Run panel opens with one field per key. All declared keys are required — running with a missing key would send the literal unresolved placeholder to an agent, so the console collects them first.
• If the pipeline declares no user inputs, the run starts immediately. An optional panel still lets you pass extra fields as raw JSON if an agent expects them.
• A JSON toggle on the panel lets you supply the whole input object by hand for irregular shapes.

Scheduled workflows start runs the same way, automatically, at the configured recurrence — those executions appear in the same list as manual ones. So do runs started from the workflow's webhook trigger, attributed to the webhook principal.

The executions list

The workflow detail page lists all of its executions with the execution id (its last 8 characters — hover for the full id, handy for matching a row against audit events or API responses), started time, status, completed time, and duration. Timestamps render in your local timezone. The Started and Completed headers sort the table (newest completed first by default; a still-running execution slots in by its start time). Click any row to open the execution page. Execution statuses you will see:

• Running — the run is in progress. A run also stays Running while a step is waiting on a person (see Steps that wait on a person) — waiting is shown on the step, not on the run.
• Completed — every step finished and the run closed normally.
• failed — a step errored or timed out; the run stops and the error is recorded on the execution.
• onhold / aborted — the run was paused or cancelled before finishing. An onhold (or failed) run can be resumed by API clients: starting the workflow again with the execution id re-runs the current step, optionally with additional inputs merged in.

Inside an execution

The execution page shows the run end to end:

• Header — execution id, start/completion timestamps, and a live status chip. While the run is in progress the page re-fetches automatically every few seconds, so you can watch it without reloading.
• Error banner — if the run failed, the recorded error appears at the top.
• Inputs — the input object the run started with, rendered as readable key/value rows; a braces toggle shows the raw JSON.
• Step timeline — one row per pipeline step, in order. Each agent row shows the agent, its status, its timestamp, its output (when the agent returned one — message text as prose and data fields as key/value rows, with the raw JSON behind a braces toggle), and its error (when it failed). Because the execution snapshots its pipeline at start, the timeline shows every step from the beginning: the currently executing step pulses as running, steps not yet dispatched render as queued, and finished steps carry their real reported status. A step's reported status is one of running, completed, failed, input-required, or auth-required — the last two mean the step is waiting on a person (see below). Executions from older platform versions may show Success where completed is meant. Non-agent steps join the same timeline: switch rows render the branch decision (input, resolved value, matched case, next node), steps on untaken branches show as skipped, and a step parked at an approval gate shows awaiting approval with a link to the Approvals page.
• Runtime events — the audit trail emitted during this run: tool calls, LLM calls, egress decisions, and denials, each tagged with the emitting agent. Events are grouped into one expandable section per pipeline step (header: step number, node id, dispatched agent, event count, time range, and a denials chip when any were denied); steps containing a denial or error start expanded, the rest collapsed, and workflow-level events such as run start and completion stay as standalone rows in stream order. The step lifecycle events themselves carry short previews — the dispatched message on workflow_step_started and the returned output on workflow_step_completed (truncated, and omitted entirely for workflows whose payload capture is switched off via the API). This is the same event stream the Security section reads, correlated to the run by execution id.

Steps that wait on a person

A step does not always run to completion in one go — an agent can pause its work until a person acts. The step then shows one of two waiting statuses in the timeline:

• auth-required — the agent needs someone to connect or authorize an account before it can use a tool on their behalf (for example, a delegated integration the user has not connected yet).
• input-required — the agent asked for more input or an approval before continuing (for example, a governed action deferred to an approver).

A third waiting state comes from the workflow itself rather than an agent: awaiting approval, when the run reaches an approval gate authored into the pipeline. It behaves the same way — the run stays Running, the decision is made on the My Approvals page — but it waits on the gate's own timeout (72 hours by default) instead of the step time limit below.

While a step waits, the run itself stays Running — waiting is a per-step state, and the step row records why it is waiting and since when. The runtime events for the execution carry a matching Step awaiting user (workflow_step_waiting) event, which also appears in the Governance section's event stream, so waiting runs are visible outside the execution page too.

Nothing needs to be restarted: once the person acts — connects the account, supplies the input, or approves the action (see Approvals for deferred tool calls) — the run picks up on its own and the step continues. A waiting agent step is still subject to the step time limit below, and an approval gate to its own timeout policy, so a run never waits forever: if nobody acts in time, the step fails (or the gate's on-timeout policy applies) and the run resolves accordingly.

Step time limits

Every agent step runs against a time budget. By default a step may run (or wait) for 35 minutes; when the budget expires, the step is marked failed with a "step timed out" error and the run is marked failed. The limit applies from the moment the step is dispatched, including any time spent waiting on a person.

API clients can override the budget per step by setting timeoutSeconds on a pipeline node; your platform operator can also change the default. Steps without an override use the default. Approval gates are the exception: a gate waits on its own authored timeout (default 72 hours) and resolves per its on-timeout policy, not the step budget.

Interruptions and restarts

Runs are durable: an execution in progress survives platform restarts and upgrades. If the platform is interrupted mid-run, the run is picked up again automatically — steps that already finished keep their results and are not re-run, and the run continues from the step that was in flight. Waiting steps stay waiting across a restart; nobody has to re-trigger anything.

One consequence to know: step delivery is at-least-once. If an interruption hits at exactly the wrong moment (both the platform and the agent lost track of the attempt), the in-flight step is dispatched again rather than silently dropped. Each attempt carries the same stable X-Workflow-Execution-ID and X-Workflow-Step-ID request headers, so agents whose actions must not happen twice can use them to deduplicate — see Agents in workflows for what agents receive on dispatch.

Diagnosing failures

When a run fails, work top-down:

1. Read the execution-level error banner — it names what stopped the run.
2. Find the first failed row in the step timeline; its inline error message is the agent's own report.
3. Check the runtime events for that step — its group is expanded automatically when it contains a denial or error, so a blocked egress call, a denied tool, or a failed LLM call is usually one click away.
4. If the failure was an unresolved input, re-run with the missing $userinput key filled in; the placeholder substitution happens before any step dispatches, so such runs fail immediately without touching an agent.
5. A step timed out error means the step exhausted its time budget — often a step that was waiting on a person nobody acted on, or an agent that hung. Check whether the step was in a waiting state first, then re-run (or resume via the API) once the blocker is resolved.

Follow-up questions and file inputs

Two additional capabilities are available on the platform API:

• Execution chat — each execution keeps a conversation thread, so a client can ask follow-up questions about a run's results and retrieve the message history for that execution.
• File uploads — for workflows whose inputs include files, the API issues short-lived upload URLs so files can be uploaded directly to storage and referenced by the run.

Both are exposed to API clients; the console does not currently surface a screen for them.