Run inspector and replay
Inspect a workflow's runs and their steps, and replay a whole run.
- Product stage
- Development build
- Last reviewed
- 2026-08-27
- Successful result
- The change is visible in the active project.
What this accomplishes
Inspect a workflow’s runs and their steps, and replay a whole run. The run history has two levels: the run itself, and the steps inside it. Expand a run to see each step’s status, duration, and retry count; open a step to see its full input, output, and any error.
This page is the run inspector. The local scheduler is in local scheduler; dry-run mode is in dry-run mode.
Current availability
This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.
Before you start
- A Miton development build, an active project and Automation open.
- A connected model plus permission for every file, network or scheduled action in the workflow.
The run list
Every run for the workflow appears newest-first. Each row shows:
- Status indicator — running, suspended (“waiting for input”), succeeded, or failed.
- Trigger — manual, scheduled, or webhook.
- Started at, and once finished, how long the run took.
- A pass/fail/skip step count once the run has steps.
A failed run shows its error inline under the row.
The steps inside a run
Expand a run to see its steps in execution order. Each step shows its node id, node kind, status, duration, and — when the executor retried it automatically — a retry count badge. Click a step to open its inspector:
- Inputs and Output — the JSON the step received and produced.
- Error — the step’s error, if it failed.
- Duration, and the retry count if the step was retried.
- Copy step JSON — copies the step’s full record (id, node kind, status, input, output, error, timing) to the clipboard in one action.
Replay
Replay, at the bottom of an expanded run, starts a new run from the same workflow graph. The new run is a separate row in the history — it doesn’t rewrite or attach itself to the run you replayed from — though its subtitle notes what it replayed. There’s no isolated single-step replay that reruns just one node in place; replay always starts the workflow over as a new run.
Delete removes a run from the history.
What the run inspector does not cover
- Replaying a single step in isolation — replay restarts the whole workflow as a new run.
- Filtering, sorting, or exporting run history — there’s no built-in CSV/JSON export, and no filter by status, trigger, or date range beyond scrolling the list.
- Editing a step’s input before replay — a step’s recorded input is fixed; use a dry run with a fixture instead if you want to try a workflow against a different input.
What success looks like
You can find a failed run, drill into the step that failed, read its exact input and output, and decide whether to fix the workflow and replay it or address the underlying system it called out to.
Common failures and recovery
- Inspect the failed run and the exact node output before replaying it.
- Confirm credentials, permissions and test fixtures belong to the active project.
- Use a dry run to isolate a misconfigured node before starting the complete workflow again.
Related next action
Open the Automation overview to connect this task to the rest of the workflow.