Run inspector and replay

What this accomplishes

Inspect workflow runs step by step and replay or retry individual steps.

The run inspector is where you inspect a workflow’s runs and replaying individual steps. The inspector has two levels: the run as a whole, and the steps inside the run. The user can drill into a step, see the step’s input, see the step’s output, see the step’s log, replay the step, or retry the step.

This page is the run inspector. The blog post on the inspector is at two-level run history; the local scheduler is in local scheduler; the 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 as a whole

The run list is the first level. The list shows every run the workflow has produced, sorted newest-first. Each row has:

• Status — running, succeeded, failed, suspended.
• Trigger — the trigger that started the run (schedule, webhook, chat command, manual).
• Started at — the timestamp the run started.
• Duration — the elapsed time the run took.
• Cost — the model cost (if any) and the per-trigger cost (if any).

The user can filter the list by status, by trigger, by date range. The user can sort by any column. The user can export the list to CSV or JSON.

The steps inside the run

The run details are the second level. The details show the run’s trigger, the run’s environment (the model, the routing profile, the budget state), and the run’s step list.

The step list shows every step the workflow executed, in the order the workflow executed them. Each step has:

• Step name — the name of the node the step represents.
• Status — running, succeeded, failed, skipped.
• Started at — the timestamp the step started.
• Duration — the elapsed time the step took.
• Input — the input the step received (the output of the previous step, or the trigger payload for the first step).
• Output — the output the step produced (for the next step, or the final output for the last step).
• Cost — the model cost (if any) and the per-step cost (if any).
• Log — the step’s log: the model’s prompt, the model’s response, the tool calls, the tool results, the errors.

The user can click a step to see the full details. The full details show the input and output in a diff view (for the steps that produce a structured output), the log in a scrollable panel, the environment at the time of the step.

The per-step replay

The per-step replay is a CoW panel that lets the user re-run a step in isolation. The user clicks “Replay” on a step; the replay dialog opens. The dialog shows the step’s input, the step’s environment, and a “Replay” button.

The user clicks “Replay”; the step runs with the same input and the same environment. The replay is a new step in the run history; the user can see the replay’s input, output, duration, cost, and log. The replay does not affect the original run’s history; the replay is a separate step.

The replay is rate-limited. A user cannot replay the same step 100 times in a minute; the replay is rate-limited at 10 replays per minute per step. The rate limit prevents the user from accidentally incurring a large model cost on a misconfigured step.

The per-step retry

The user can retry a failed step without re-running upstream steps. The user clicks “Retry” on a failed step; the step runs again with the same input. The retry is a new step in the run history.

The retry is useful for transient failures. A user whose workflow failed because the model API was down for 30 seconds can retry the failed step without re-running the upstream steps that succeeded. The retry is a one-click affordance.

The retry is also useful for user-corrected steps. A user who sees a step’s output and wants to correct the step’s input can edit the input and retry. The retry is a “re-run with my fix” affordance.

The per-node log

The per-node log is the step’s full log. The log includes:

• The model’s prompt.
• The model’s response.
• The tool calls.
• The tool results.
• The errors.
• The warnings.

The log is scrollable; the user can search the log for a keyword; the user can copy any line of the log. The log is preserved for the lifetime of the run.

The per-node log is the audit trail for the workflow. The user can use the log to debug a failure, to verify a compliance posture, to document a workflow’s behaviour, to share a run with a collaborator.

The export

The user can export the run’s data to a JSON or CSV file. The export is a download. The JSON is a complete dump of the run’s data, including the run’s trigger, the run’s environment, the run’s step list, each step’s input, each step’s output, each step’s log.

The CSV export is a flattened version of the run’s data. Each row is a step; the columns are the step’s name, status, start time, duration, cost. The CSV is useful for analysis in a spreadsheet.

The export is per-run. The user can also export multiple runs at once from the run list.

What the run inspector does not cover

The run inspector does not cover:

• Real-time run streaming — the run inspector shows the run’s data after the run completes. The user cannot stream the run’s data in real time. The user can use the dry-run mode for real-time testing.
• Run comparison — the inspector shows one run at a time. The user can compare two runs by opening them in two browser tabs.
• Run annotations — the inspector shows the run’s data as-is. The user cannot add annotations to a run. The user can use a third-party tool for run annotations.

The run inspector focuses on the post-run analysis. The less common cases are covered by the user’s existing tools.

What success looks like

The run inspector is the right shape for debugging workflows. The user can see the run as a whole, the steps inside the run, the input and output of each step, the log of each step. The user does not have to re-run upstream steps to debug a downstream step.

Use the replay surface to debug a failing step. Click “Replay” on the failed step; iterate on the input and the environment; promote the corrected step to the canonical workflow when the replay succeeds.

Use the retry affordance for transient failures. If the model API was down for 30 seconds, retry the failed step. The retry is one click; the upstream steps that succeeded are not re-run.

The per-node log is the audit trail. The log is preserved for the lifetime of the run. The log is on the user’s disk; the log is not uploaded to a Miton server.

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 dry-run or step replay before starting the complete workflow again.

Related next action

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