Automate

Inspect and manage runs

A run is one execution of a deployed workflow. The workspace Runs page is the operational history for manual, webhook, scheduled, API, MCP, child-workflow, and rerun activity.

Last reviewed July 14, 2026

In the app Automate → Runs

Problems this solves

Start with the recurring problem, then use this feature when its boundary matches the outcome you need.

Problem

Find why an automation failed

A scheduled job did not produce the expected result, and nobody knows whether it started or which operation failed.

How this helps

Use Runs to inspect the trigger, input, step timeline, error, output, duration, and parent/child execution chain.

Problem

Prove recurring work actually happened

A background integration is supposed to run all day, but a missing result is only noticed much later.

How this helps

Filter Runs by workflow and status to verify each scheduled execution and investigate failures or dead-letter work.

See the scheduled calendar-sync workflow →

Find a run

Choose All, Running, Succeeded, or Failed.
Narrow the list to one workflow if the workspace has many automations.
Choose All time, 24 hours, 7 days, or 30 days, or search by workflow text.
Select a row to open its detail page.

Each row identifies the workflow, project and environment, current status, trigger source, duration, and start time. The list refreshes while active runs are changing state.

Read the run detail

Status and trigger: Confirm whether execution is queued, active, completed, failed, or cancelled and what started it.
Timeline: See workflow steps and their relative timing. Expand errors for the step name, message, and available stack trace.
Timing: Compare created, started, completed, and total duration timestamps.
Input / Output: Inspect the JSON received by the workflow and its returned output or error.
Parent run: For a child workflow, follow the link back to the run and step that spawned it.

Stop an active run

Select Stop Workflow while a run is pending, running, sleeping, or waiting. Cancellation also propagates to child execution. Stopping cannot undo side effects that already happened in an external system.

Rerun a finished workflow

Completed, failed, and cancelled runs have a Rerun action. It creates a new execution from the beginning with the prior trigger input. Review the input first: rerunning may send the same email, charge the same API, or repeat another external side effect.

Old run details are retained according to your plan.

After detailed output, logs, and step data are purged, SolidActions keeps status and timing metadata but no longer allows that run to be used as a rerun source.

Triage runs that exhausted retries

When failures pass their retry budget, a red triage band appears above the run list. Fix the underlying problem, then choose Retry; choose Acknowledge when no more action is required. Bulk Retry all and Acknowledge all actions apply the same decision to every visible dead-letter item.

Inspect from the CLI

Start an on-demand execution and wait for its result:

solidactions run start my-project my-workflow \
  -e production \
  -i '{"name":"Ada"}' \
  --wait

Then list or inspect runs without opening the app:

solidactions run list my-project -e production --status failed
solidactions run view RUN_ID --steps
solidactions run view RUN_ID --logs

Use --json for scripts, and run list --detailed --has-errors when you need a compact diagnostic view across several executions.

Next: learn how triggers start runs or useTroubleshooting when a deployment or result is wrong.