- Introduction
- Getting started
- Building with Maestro BPMN
- Understanding Maestro BPMN modeling
- Opening the modeling canvas
- Modeling your process
- Aligning and connecting BPMN elements
- Autopilot for Maestro (Preview)
- Process Repository
- Implementing a simple BPMN process
- Implementing a complex BPMN process
- Debugging
- Simulating
- Evaluations (Preview)
- Common implementation scenarios
- Building with Maestro Case
- Introduction to Maestro Case
- Maestro BPMN vs. Maestro Case: when to use case management
- The Maestro Case lifecycle: from event trigger to app experience
- Build your first case with Maestro Case
- Build a Maestro Case with a coding agent (preview)
- Defining case keys (system vs. external)
- Establishing task I/O and write-back contracts
- Exit rules and early stage termination
- Modeling primary and secondary stages
- Triggering a case from Data Fabric
- Implementing stage-level personas and permissions
- Setting SLAs and automated escalation rules
- Configuring a rework loop (re-entry)
- Configuring and testing the Case Manager Agent (preview)
- Case Manager input and output contract
- Maestro Case component dictionary
- Building with Maestro Flow
- Maestro Automate
- Integrations
- Operating
- Monitoring
- Optimizing
- Reference information
Execution history and per-run traces for deployed Flow workflows, showing what triggered each run, the path it took, and per-node output and timing.
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.
Related Maestro instance management topics
- Instance diagram view — status icons per process step
- Instance throttling — automatic throttling of a workflow instance under high activity volume
- Custom instance ID — a runtime-derived instance ID in place of the system-generated one
Execution history
The execution history lists every run of the workflow, with the following information for each:
| Field | Description |
|---|---|
| Status | Succeeded, Failed, or Running. |
| Trigger | What started the run (manual, scheduled, or integration event). |
| Started at | Timestamp of when the run began. |
| 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)
- Trigger type
- Date range
- Version number
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
Failedstatus. - 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.