> ## Documentation Index
> Fetch the complete documentation index at: https://docs.letsflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Run history and debugging

> Find automation runs, understand failures, and recover safely.

Open an automation and select **Run history** for its runs. Use **Automations → Monitoring** to
check active runs, recent failures, and blockers across the teams you can access.

## Investigate a run

<Steps>
  <Step title="Open Automations → Monitoring." />

  <Step title="Choose the team and time range." />

  <Step title="Search by public run key, ticket title, ticket key, run ID, or automation." />

  <Step title="Open the run actions and select Open run." />

  <Step title="Review the input, output, diagnostic, steps, approvals, actions, and events." />
</Steps>

Monitoring includes production and test runs, active runs of any age, and finished runs with
activity in the selected time range. Active runs appear first. Search, filters, and pages cover
all matching runs. For scope and failure analysis details, see
[Monitor automations](/automations/monitor).

**Analytics → Dashboard** reports aggregate production-run success for its selected teams and period.
Its totals can differ from Monitoring because the views include different runs.

For a failed run, select **Debug this run** in the Flow composer. Flow checks that run's recorded
steps and the source version it executed. It consults relevant action guidance and current
connection health when the evidence calls for them. If source access is unavailable, Flow says so
rather than using a newer version.

Diagnosis is read-only. Flow explains the evidence and may propose an automation change,
a connection remedy, or another check when the cause is uncertain.
It asks for approval before switching from **Ask** to **Build** for an edit.
Diagnosis does not rerun the automation or change a connection.

Keep the request and correlation IDs when contacting support.

## Edit after diagnosis

Opening a run switches Flow to **Ask** and keeps the run read-only,
even when it used the latest automation version.
Questions and diagnosis do not require a mode switch.

If you ask Flow to apply a change, it shows a **Switch to Build mode?** card.
Select **Switch to Build** to return to the current automation and continue
the request in **Build**. The conversation and run tab stay open.
Flow edits the current draft, not the run's historical source.

Flow must save unsaved draft changes before continuing.
If saving fails, you return to **Ask** in the run view.
The approval stays pending. Resolve the save problem and retry,
or select **Stay in run view**.

Select **Stay in run view** to decline without applying the change.
You can continue discussing the run.

This mode approval does not publish or run the automation.
Once in **Build**, Flow does not request mode approval for each edit.
Returning to **Ask** does not require approval.
Approval to run an automation is separate.

## Run states

| State | Meaning |
| - | - |
| **Pending** | Flow has requested or queued the run |
| **Running** | The automation is executing |
| **Waiting** | Approval, input, or another condition is required |
| **Cancel requested** | Flow has requested that the run stop |
| **Success** | The run finished |
| **Failed** | The run ended with an error |
| **Denied** | Authorization or approval prevented completion |
| **Canceled** | The run stopped before completion |

## Recover a run

Use **Cancel run** to request cancellation. The run can finish or fail before cancellation takes
effect. Read its final status to see the outcome. After you request cancellation, an authorized
operator can use **Terminate run** to stop execution immediately.

An external action can finish after the run stops. Cancellation does not undo actions that a
connected app has accepted. Run details show a warning when an external action may have taken
effect, including when its outcome remains unconfirmed. Check the connected app before you rerun
an action that changes data.

**Rerun** appears only for eligible terminal, live, manually started production runs. It creates a
new run using the currently published version and current authorization.

For API requests, use the returned `runKey` to read, cancel, or rerun a run.

Monitoring marks a rerun and links to **Original run** when you have source access. If the source
run is unavailable to you, its link is unavailable. Deleting a source run removes the retained
rerun connection.

Before rerunning, confirm that:

* Repeating connected-app actions is safe.
* The published version has not changed unexpectedly.
* Current connections and inputs are correct.

Flow can retry supported transient failures while a run is active. If an action may have changed a
connected app, Flow cannot confirm the result, and the integration cannot safely repeat the action,
Flow stops automatic resend and reports an uncertain outcome. Check the connected app before
rerunning. The action might have succeeded, or the request might never have reached the app.

For example, if an onboarding ticket creation times out, check whether the ticket exists before
starting another run. A rerun can create another ticket.

Automation authors can select `retry: "none"` to disable automatic resend for a connected-app action.
This choice can leave the action unfinished after an interruption. Default retries and provider
support for duplicate-request protection also cannot guarantee delivery. You cannot manually retry
one step inside the same run.

## Related topics

* [Troubleshoot automations](/setup/troubleshooting/automations)
* [Publish and execution scope](/automations/build/publish-and-execution-scope)
* [Versioning and organization](/automations/manage/versioning-and-organization)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.