English

日本語

English

日本語

Appearance

Debug a failed execution ​

When a flow doesn't do what you expected, its execution shows which step went wrong and what that step was working with. This page walks through finding the run, reading the failing step, and trying again.

1. Find the execution ​

Open Executions in the sidebar. To narrow the list:

  • Set Status to Failed and Timed out.
  • Pick the flow in Flows.
  • If you have the run's ID, for example from a Call Sub Flow step's subFlowRunId, paste the full ID into Run ID.

While you're in the flow editor, Run history shows the flow's Recent Runs and is often quicker.

The list only goes back 14 days. See Executions.

2. Open the failing step ​

Click the run. In Run nodes, the step that failed is marked Failed. Select it and open the Error tab to read why, for example an HTTP status and the API's message, or a missing required field.

If the run is Timed out instead, look for the last step that ran. It was usually still running, or waiting, when the run ended.

3. Compare input and output ​

Most failures come from the data a step was given rather than the step itself. Check, in order:

  1. The failing step's Input tab: the settings as they were after references were filled in. Look for empty values, or reference text such as $.01JA9F….output.email left where you expected an address. Either means a reference found nothing.
  2. The Output of the step that the reference points to. Check the field is there, has the name you used, and sits where you expected, for example inside a list.
  3. Steps marked This step did not run. If the failing step refers to a step on a branch that wasn't taken, that step has no output in this run.

For a step inside a loop, pick the iteration that failed. For a Call Sub Flow step, open its Sub-flow runs and debug the sub-flow's own run the same way.

If the banner says the flow was edited since this run, the graph shows the flow as it ran, which may not match the editor.

4. Fix it and run again ​

There's no button to re-run an execution. Fix the flow, then run it again:

  1. Click Open flow in editor.
  2. Change the step or the data it refers to.
  3. Test with Run. This needs a Manual trigger. To avoid real side effects while you test, such as sending email, give those steps a Sample Payload in Nodes Setting. See Testing while you build.
  4. Check the new run in Run history.
  5. Publish. Webhook, schedule and event triggers run the published version, so until you publish they keep running the version that failed. See Versions and publishing.

If the original input matters, for example a form response, send the event again from its source after you publish, or copy the trigger's Output from the failed run to rebuild a test case.

If a step can fail and that's fine ​

Some failures are expected, such as an API returning Not Found for an unknown customer. Set that step's Error Handling to Continue flow in Nodes Setting, then use a Path to handle the missing result. See When a step fails.