> ## Documentation Index
> Fetch the complete documentation index at: https://keystroke.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflow runs

> Inspect workflow executions, payloads, errors, and traces.

A workflow run is one execution of a workflow. It records the workflow input, output or error, status, timing, trigger context, usage, and trace data.

Use workflow run history when you want to debug a failed automation, confirm what input a workflow received, inspect its final output, or understand how it was triggered.

## Where to find workflow runs

Open **History** in the web app, then filter **Type** to **Workflow**. Select a run to inspect its details.

The History page is shared across workflow and agent runs. See [Run history](/docs/learn/logs/overview) for the full table, filters, statuses, and detail tabs.

## What starts a workflow run

Workflow runs can start from:

| Source                    | Example                                                                         |
| ------------------------- | ------------------------------------------------------------------------------- |
| **API or CLI invocation** | `keystroke workflows run signup-pipeline --input '{"email":"ada@example.com"}'` |
| **Webhook trigger**       | An inbound HTTP request attached to a workflow                                  |
| **Schedule**              | A cron source attached to a workflow                                            |
| **Poll trigger**          | A polling source that found new work                                            |
| **Workflow tool**         | Another runtime path that invokes the workflow as a tool                        |

The trigger label in History tells you how the run started. The Metadata tab includes both the readable trigger label and the raw trigger value.

## Inspect input, output, and errors

For workflow runs, the detail panel's **Overview** tab shows:

| Section    | What it shows                                                                                                                                                                                                       |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Input**  | The payload passed into the workflow                                                                                                                                                                                |
| **Output** | The workflow's final output after a successful run                                                                                                                                                                  |
| **Error**  | The failure payload when the run failed                                                                                                                                                                             |
| **Usage**  | Duration and cost line items recorded for the run. Model usage on your own provider keys is labeled **Your API key** and excluded from the billed total — see [Managed services](/docs/learn/settings/managed-services). |

Payloads can be viewed as JSON or YAML and copied from the detail panel.

The **Metadata** tab shows run identity, actor, project, trigger, queue time, start and finish times, models used, services used, and total cost. The **Trace** tab shows raw spans and logs when trace data is available.

## Use the CLI

Use `keystroke workflows runs` when you know which workflow you want to inspect:

```bash theme={null}
keystroke workflows runs list signup-pipeline --status failed
keystroke workflows runs get signup-pipeline <run-id> --wait --timeout 60
keystroke workflows runs get <run-id> --summary
keystroke workflows runs get signup-pipeline <run-id> --field error
keystroke workflows runs get signup-pipeline <run-id> --include trigger,steps,trace,children
```

Use `--wait` for an active run instead of polling it with a shell loop. If the bounded timeout elapses, the command returns the latest running state with exit code `0`; run the same command again to continue waiting.

You can cancel a queued or running workflow run:

```bash theme={null}
keystroke workflows runs cancel <run-id>
```

Use `keystroke history` when you want cloud history across workflows and projects:

```bash theme={null}
keystroke history list --kind workflow --status failed
keystroke history get <run-id>
```

`workflows runs` inspects runs for a specific workflow on your deployed project. `history` is for platform run history across the active organization. See the [CLI reference](/docs/cli#workflows) for command details.

## Next steps

<CardGroup cols={2}>
  <Card title="Run history" href="/docs/learn/logs/overview">
    Learn the shared History table and detail panel.
  </Card>

  <Card title="Run workflows" href="/docs/learn/workflows/run-workflows">
    Start workflow runs and inspect their results.
  </Card>

  <Card title="Build workflows" href="/docs/learn/workflows/build-workflows">
    Define workflows and compose actions.
  </Card>

  <Card title="Agent runs" href="/docs/learn/logs/agent-runs">
    Compare workflow executions with agent sessions.
  </Card>
</CardGroup>