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.

Open the Automation overview to connect this task to the rest of the workflow.