Skip to main content
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

1

Open Automations → Monitoring.

2

Choose the team and time range.

3

Search by public run key, ticket title, ticket key, run ID, or automation.

4

Open the run actions and select Open run.

5

Review the input, output, diagnostic, steps, approvals, actions, and events.

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. 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

​
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.