Read a single run in full

Reference for the run detail page: status, duration, trigger payload, and the step-by-step timeline with input, output, console, and error data.

The run detail page shows everything about one execution of a workflow: its status and timing, the payload that triggered it, and a step-by-step timeline you can expand to read each step's input, output, console output, and any error.

You reach it from Monitoring in the workspace sidebar. Open Runs, then click a run's ID in the table. The URL is:

/<workspace-slug>/monitoring/workflow-runs/<workflow-id>/<run-id>

The breadcrumb at the top reads Monitoring / Workflow Runs / Workflow {id} / Run {id}, where each id is the first 8 characters of the full identifier.

Page layout

The page has two parts stacked vertically:

An overview at the top: workflow name, run id, status, timing, progress, an error banner when the run failed, and the trigger payload.
The Execution Steps timeline below it: one collapsible row per step.

A header on the right holds a Refresh button and a File incident button. File incident is an advanced feature that stays disabled unless the run contains a permission-gated event; the tooltip when disabled reads "File incident requires a permission event on this run." You can ignore it for ordinary integration runs.

Auto-refresh

While a run is pending or running, the page polls for updates every 10 seconds. Polling stops the moment the run reaches a terminal status, and it pauses while the browser tab is in the background. A completed run will not update on its own; that is expected, not a frozen page. Use Refresh to fetch the latest state at any time.

Overview fields

The compact metadata grid in the overview shows these fields.

Field	Type	Description
Workflow ID	string (monospace)	The full identifier of the workflow this run belongs to.
Started	relative time	When the first step started. Shows nothing until a step starts.
Completed	relative time	When the run reached a terminal status. Empty until then.
Duration	formatted duration	Elapsed time between start and completion.
Progress	`{completed} / {total} steps`	Completed step count over total step count, with a thin progress bar below.

The top row of the overview also carries the workflow name (or "Workflow Run" if unnamed), the full run id in monospace, the status badge, and a "triggered by" badge for non-production runs.

Triggered-by badges

A run started outside of normal production traffic carries a badge that names how it began. A plain production run shows no badge.

Badge	Meaning
Manual	You started the run by hand from the per-workflow Run dialog.
Sampled	A sampled copy of a production run.
Publish gate	A test run from the publish validation step.
Scheduled	Started by a schedule.

Run statuses

A run is always in one of seven statuses. The status badge in the overview shows the raw value.

Status	Meaning
`pending`	Accepted, not yet started executing steps.
`running`	One or more steps are executing now.
`paused`	Held by a pause action; resumable.
`waiting`	Blocked on an external condition, such as a client authorizing an app.
`completed`	All steps finished successfully. Terminal.
`failed`	A step errored and the run stopped. Terminal.
`cancelled`	Stopped by a cancel action. Terminal.

For what each status means for pausing, resuming, and cancelling, see Control a run. For a full status-by-status reference, see Run and step statuses.

Trigger payload

Below the overview, the page renders the payload that triggered the run as a JSON preview. This is the trigger step's output: the event body that the rest of the workflow read from.

If the run was started by a form, a form-submission panel renders here instead of the JSON preview, showing the submitted fields.

Execution Steps timeline

The Execution Steps section lists every step in order, with a count of total steps and badges summarizing the breakdown: "N completed", "N running", "N failed", "N waiting", "N paused".

When any step failed, a Jump to failed step link appears in the section, and the first failed step expands automatically so you land on the problem.

Each row, collapsed, shows:

A status icon and the 1-based step number.
The step title.
The node kind badge, such as http.request.
A Beta badge if the step's definition is in beta.
A status badge and the step's duration.

Expanded step contents

Click a row to expand it. The expanded panel stacks the following sections. There is no four-tab Input/Output/Console/Error strip; Error is an alert, and Input, Output, and Console are separate sections.

Read the error alert
If the step errored, a red alert appears at the top of the panel. Its title is the error code (for example AUTH_MISSING or TIMEOUT), or "Error" when the code is UNKNOWN_ERROR. The body holds the error message in monospace.
When the runtime knows more, the alert adds: "Provider status: {N}" (the HTTP status the upstream provider returned), a " (retryable)" suffix when a retry is sensible, and "Retrying in {N}s" when the runtime has already scheduled an automatic retry. A collapsible Technical details disclosure holds the raw detail string and the error code for support.
Check the timing block
Started, Completed, and Duration for this individual step.
Note the identifiers
Step ID in monospace and Operation, the canonical reference for what ran (for example trigger.gmail.email_received). A collapsible Technical details disclosure holds Version, Definition ID, and Connection ID for support.
Inspect Input and Output
Input (Database icon) is the data the step received. Output (Code2 icon) is the data it produced. When a step has no data, the section reads "No input data available" or "No output data available."
Each of Input and Output has its own sub-tabs for viewing the data, described below.
Read Console output
Console (Terminal icon) appears only for code steps that emit console output. When empty it reads: "No console output. Call console.log() from your code to capture diagnostics." Console output truncates at 100 lines or 10 KB, whichever comes first.

Input and Output sub-tabs

Input and Output each render the data through the same viewer, which offers these sub-tabs.

Tab	When shown	Shows
Tree	Always	An expandable tree of the data structure. The default view.
Table	Only when the data is an array of objects	One row per array item, columns for the fields.
JSON	Always	The raw JSON.
Meta	When metadata is present	Step metadata for the data pane.

Waiting on a client connection

If a step is waiting because it needs a client to authorize an app, the expanded step shows a Waiting on client connection alert:

Awaiting {email} to authorise {app}. The run will resume automatically when the client completes the OAuth handshake.

The run resumes on its own once the client finishes authorizing; you do not need to restart it. See Request client credentials for how to send that request.

Error codes are open-ended

Error codes are not a fixed list. The step alert shows whatever code the runtime returned. Only UNKNOWN_ERROR and CANCELLED are guaranteed constants; codes like AUTH_MISSING and TIMEOUT are conventions, not an enumerated set. Read each error by its shape, the code plus the message, the provider status, and whether it is marked retryable, rather than looking it up in a closed table. To work a failure end to end, follow Debug a failed run.

Limits

Console output per code step truncates at 100 lines or 10 KB.
Auto-refresh runs every 10 seconds and only while the run is pending or running. It does not poll terminal runs or background tabs.
This page has no replay control. Re-running a run is a separate surface and is not reachable from this page.

What is not on this page

This is the simpler monitoring run view. It does not have replay, preset filter chips, cost or model filters, a live tail, or full-text run search. Those belong to a different, agent-focused run viewer and are not part of watching ordinary integration runs.

Find and filter runs lists every run and links into this page.
Debug a failed run walks a failure from the timeline to a fix.
Control a run covers pause, resume, and cancel.

Webhook