Skip to main content
Every time a workflow runs, it creates an execution record. Use executions to monitor what’s happening and troubleshoot issues.

​
History range

The execution history view has a range selector to control how far back you can see runs. On non-Enterprise plans the 30-day option is shown but locked behind an upgrade prompt. Existing execution records older than your range are not deleted — they just aren’t surfaced in the dropdown selection.

​
Execution statuses

A Pending execution means one of two things: it is about to start, or it is waiting behind the concurrency cap. The UI shows the same status for both.

​
Concurrency limits

Nedzo caps how many executions run at the same time. Support can raise both caps. It is not self-serve, so email support with the number you need and why.

​
What happens when you hit the cap

Enroll a large batch and the runs past the cap sit in Pending instead of failing. They wait up to 3 hours and start as soon as a slot frees up. Before this change they failed after about 14 seconds. An execution still queued after 3 hours fails. The error names the cap it waited on, so you know whether to split the batch or ask for a higher limit.

​
What’s tracked

Each execution records:
  • Trigger type and data — What started the workflow and the data it carried
  • Current position — Which node is executing (or waiting)
  • Step outputs — The result of each completed step
  • Error details — What went wrong if a step failed
  • Timestamps — When it started, completed, or failed

​
Step outputs

Every action stores its output after running. These outputs are available to later steps as variables. For example, a voice call step stores:
  • Call ID
  • Status and call disposition
  • Extracted data fields
  • Recording URL
A webhook step stores:
  • HTTP status code
  • Response body

​
Testing

Individual steps can be tested from within their configuration panel. Step-level testing lets you verify each action works correctly before publishing. Test executions are flagged separately and don’t count against limits.

​
Troubleshooting

​
Workflow didn’t trigger

  • Check that the workflow is published and the activate/deactivate toggle is set to active
  • Verify the trigger conditions match the event
  • Check deduplication — the same trigger for the same contact within the dedup window (default 1 minute) is ignored

​
Step failed

  • Check the error message in the execution details
  • Common causes: missing integration connection, invalid phone/email, expired OAuth token
  • Transient failures (network issues, rate limits) are retried automatically up to 3 times. Time spent waiting on the concurrency cap is not a failure and does not spend a retry.

​
Workflow stuck on “Waiting”

The workflow is paused on a delay node. It will resume automatically at the scheduled time.