Observing runs

Once a Flow is deployed and running, the execution history gives you a complete view of every run — what triggered it, which path it took, what each node produced, and how long each step took.

Execution history

The execution history lists every run of the workflow, with the following information for each:

Feld	Beschreibung
Status	Succeeded, Failed oder Running.
Auslösen	What started the run (manual, scheduled, or integration event).
Started at	Timestamp of when the run began.
Dauer (Duration)	Total time from start to completion.
Version	Which published version of the workflow ran.

Selecting any row opens the execution trace for that run.

Execution trace

The execution trace is a step-by-step record of what happened during a specific run. For each node, it shows:

• Input values — what the node received.
• Output values — what the node produced.
• Status — whether the node succeeded or failed.
• Duration — how long the node took to execute.
• Error details — if the node failed, the error message, type, and stack trace.

The trace highlights the path actually taken through the workflow (for example, which branch a Decision node took), making it easy to understand the full execution without reading the workflow definition.

Filtering and searching runs

You can filter the execution history by:

• Status (succeeded, failed, running)
• Triggertyp
• Datumsbereich
• Versionsnummer

Filters help narrow down failed runs after a deployment or compare behavior between two versions.

Failure monitoring

Failure notifications can come from workflow settings or from the workflow itself:

• The Alerts configuration in the workflow settings sends a notification to a specified email or Slack channel when a run reaches the Failed status.
• A notification step on a node's error path provides more control over the alert content.

Common mistakes

• Only checking failed runs — Slow successful runs can indicate performance problems. Duration trends matter even when the run succeeds.
• Ignoring version numbers in traces — The version number identifies which workflow version produced the trace. A rollback does not explain what went wrong if the failed run used an older version.

Zugehörige Seiten

• Deploying a Flow
• Debugging effectively
• Fehlerbearbeitung