Run history

Every time a workflow fires (yours or a system automation's) it's recorded as a run with a per-step timeline. The run history page is where you go to answer "did it work?" after a trigger.

URL: /automation/runs
Required permission: automation.view

List view

Recent runs across every workflow (user + system), newest first. Each row shows:

• Workflow: the automation name, click to open the run detail.

• Status: one of pending, running, completed, failed, cancelled.

• Started: when the trigger fired and the engine began executing.

• Finished: when the run completed or failed.

• Error: short error message for failed runs, truncated to fit the row.

The list is paginated (50 runs per page), so the full history is reachable page by page. A search box (by workflow name) and a status filter narrow the list; both apply server-side and survive navigation.

Run detail (/automation/runs/{id})

Click through to see the full story of a single run:

Summary

• Workflow name + run ID (for support).

• Start / finish timestamps + total duration.

• Status badge.

• Error message (if failed).

Trigger context

The data that fired the workflow, typically the record that was created or updated. Shown as formatted JSON so you can see exactly what the engine saw. Includes:

• model: the class name (e.g. App\Models\Deal).

• id: the record's UUID.

• attributes: the full attribute snapshot.

• A convenience echo under the record's short name (e.g. deal.title) so step configs referenced via {{deal.title}} resolve cleanly.

Step timeline

One entry per step execution, newest at the bottom. Each entry shows:

• Step number + label (or type if unlabelled).

• Status pill: success / failed / skipped / running.

• Started / finished timestamps.

• Input / Output sections (click to expand): the data the step received and what it produced.

• Error message for failed steps, in red.

For condition steps, the output.evaluated field tells you whether the condition matched and which branch was taken. For send_email steps, the output.sent_to and output.subject confirm the final (merged) recipient and subject. For send_webhook, you get the HTTP status code + truncated response body.

Interpreting a failed run

A run goes into failed state when any step returns StepResult::failed() or throws an uncaught exception. The run-detail page shows:

1. The run's error_message: a summary at the top.

2. The failed step's error_message: more detail, usually the specific problem.

3. The step's input/output so you can see what data it was working with.

Common failures:

• send_email "not a valid email": the recipient merged to an invalid address. Check the context for a missing field.

• send_email "Subject is empty": same; the subject merged to empty because a field was missing.

• send_webhook HTTP 5xx: the remote returned an error. The response body is logged in the step output.

• condition "no field configured": the condition step has no field in its config; fix the step.

• "Unknown automation step type": the step type isn't registered in the AutomationStepTypeRegistry. Usually a code/migration drift, not something an admin can fix.

Retention

Runs are append-only audit data. Nothing deletes them automatically today. A future maintenance command will prune old completed runs; failed runs will likely stay forever for debugging purposes.