Executions

Every time a workflow runs - manually, on a webhook, on a schedule, from a form, or from Stripe - it creates an execution. The Executions page is where you go to see what actually happened.

The execution list

Open Executions from the sidebar for a paginated list of every run across your workflows: which workflow, its status, and when it started. Click into any execution for the detail view.

The per-node timeline

The execution detail page renders every node that ran as an expandable timeline entry, in the order it executed, each with:

• Status - success, failed, running, or skipped (skipped means the node sat on a Branch path that wasn't taken, or downstream of a Stop node).
• Input and output - the exact data the node received and returned, as JSON.
• Error and stack trace - when a node failed, the error message and stack are attached directly to that node's entry, not just the execution as a whole.
• Duration - how long that node took.

This is the fastest way to answer "why did this fail" - open the failed node's entry and read its input against its error, rather than guessing from the workflow graph.

Re-run

Every execution has a Re-run button that starts a brand-new execution of the same workflow with the identical trigger payload the original run received - useful for retrying a run that failed because of a transient issue (a downstream API being down, for example) without re-triggering the real event.

Re-run from a chosen node goes further: from any node in the timeline, resume a run starting there instead of from the trigger. Pipory reuses that node's recorded input from the original run, so everything upstream (and any side effects it already caused) doesn't happen again - only the chosen node onward re-executes.

Pin / mock node output

In the editor (not the execution log), you can pin a node's output to a recorded or hand-written value - the pin dialog prefills from whatever that node last actually produced anywhere in the workflow, so you start from a real shape rather than a blank editor. A pinned node is skipped and its pinned value used instead, but only for manual test runs - a real trigger (webhook, schedule, form, and so on) always executes the node for real. It's how you build and test-run downstream nodes without burning real API calls or side effects while you're still wiring things up.

Cancel and concurrency

Cancel stops a RUNNING execution from its detail view - the run is marked cancelled immediately and won't advance to further nodes. A workflow's settings can also set a concurrency cap: once that many executions are running at once, additional runs queue and wait for a slot instead of piling more load onto whatever the workflow calls out to.

Run alert destinations

A workflow's settings can name an email address and/or a Slack webhook URL to notify on failure. Pair it with an On Workflow Failure trigger for custom alerting logic, or use the built-in destination for a zero-config "tell me when this breaks."

The run dashboard

Each workflow's execution list also surfaces rollup stats over a 7-day or 30-day window: total runs, success rate, p50 and p95 duration, and the timestamp of the last failure. Use it to spot a workflow that's degrading before it fails outright.

Related

• Workflows - how the context that shows up in each node's input/output resolves.
• Flow control - retries and the error edge, which decide whether a failure ends the run.
• AI & agents - the workflow chat assistant reads this same execution data to explain failures and suggest config fixes.